Quando l’operatore intende aprire un programma applicativo ed esegue il processo MxDesk.exe, col quale gira anche MxDesk.dll, innesca un controllo tra questi file e due file con lo stesso nome che si trovano sul server in \prog\mxwin, di cui copia e aggiornamento sono a cura del programma di setup. Questi file presenti nella directory mxwin hanno lo scopo di consentire il meccanismo di autoaggiornamento. A fronte di una versione in cui varia la componente iDesk, come primo passo si aggiorna la Componente Server. Questo primo passaggio, oltre ad aggiornare MxServer, i programmi Passepartout e tutte le altre componenti, si preoccupa anche di copiare nella directory mxwin i file MxDesk.exe e MxDesk.dll compatibili con le rispettive versioni di MxServer e Passepartout (gestionale).

Così, quando lato client entra in esecuzione MxDesk.exe insieme alla propria dll, si confrontano i due file eseguiti lato client con quelli presenti sul server. Questi ultimi risultano di versione differente, per cui può scattare l’aggiornamento.

In realtà, il controllo sulle versioni della Componente Client avviene ogni volta che questa entra in esecuzione, ma per l’operatore risulta del tutto trasparente, poiché le versioni sono sempre identiche salvo quando si aggiorna la Componente Server e quest’ultima prevede una nuova versione iDesk. Solo allora è rilevata differenza e scatta la condizione d’aggiornamento. Più precisamente, scatta quando la versione iDesk del server di destinazione risulta diversa da quella d’origine. Pertanto, si contempla anche l’aggiornamento contrario, da versione superiore a inferiore (es. nel caso di ripristino backup installazione server dopo che un certo client si era connesso ed aggiornato, trovandosi ora superiore a quello più vecchio dopo il ripristino server).