If working on clients impacting changes, it is necessary to have an agent check with the server for a new configuration. This process happens regularly through normal operations but in a production environment, those timelines may not be ideal for the limited access to a client that a technician may have. This article discusses methods that can be used to force a Migration Agent to check-in with the server out of schedule.
In production systems, Agent polling intervals can be configured for a long duration between them, but when testing, troubleshooting, or performing any actions on a workstation, you may want to force an agent to poll outside of the configured polling interval.
Migration Agent for Windows
The option available to all users is to run ResetMigrationAgent.exe command located in the installation directory of the Migration Agent on a user’s workstation. Upon restart, the Migration Agent will communicate with the PST Flight Deck server and check for an updated configuration. This approach may be suitable for several situations, but if you are seeking to see some action taking place after the update, a reset agent is subject to the “Initial Sleep” configuration available in the PST Flight Deck Admin Console. For example, in a default configuration, if you were anticipating a user’s migration to start after polling the server, you would be subject to a five minute delay (by default) prior to the desired behavior being observable.
Another option to force a Migration Agent to poll the server out of schedule is dependent upon the Agent being configured to display the icon in the notification tray (systray). An example of the Migration Agent icon can be seen below:
When available, a user or operator can hit a key combination (CTRL+SHIFT) while left-clicking the icon to force the Agent to check-in with the server. Initiating this request does not reset the counter for the “Initial Delay” and observable actions are seen much more promptly.
An example of a polling interval for a Migration Agent as it appears in the Migration Agent log is as follows:
1) Client Check into the server and gets configuration version information to see if there is an updated version available (in this example there is not).
ClientCopyCore|b__c => WebServiceConnector.GetConfigVersionWithWorkTypes => CopyClientLogger.Info|Get Config Version with work types ClientCopyCore|b__c => WebServiceConnector.GetConfigVersionWithWorkTypes => CopyClientLogger.Info|ConfigVersion=16842755,WorkTypes=
2) Client queries the server to see if the users is enabled for migration and sends a list of attached files to the Core server for inclusion in the discovery results.
ClientCopyCore|b__12 => WebServiceConnector.IsMigrationEnabled => CopyClientLogger.Info |Is Migration Enabled ClientCopyCore|b__12 => WebServiceConnector.IsMigrationEnabled => CopyClientLogger.Info |Is Migration Enabled - True ClientCopyCore|MainForm.UpdateWorker_DoWork => ExecutingProcess.UpdateWorkItemsProcess => ExecutingProcess.ProccessScanAttached |Get Attached enabled. Send list to server, file count:0
3) Once seeing the user is enabled for migration the agent checks to see if there is any work to be done. In this case, it requested the prompt to be displayed for the files listed.
ClientCopyCore|ExecutingProcess.UpdateWorkItems => WebServiceConnector.GetWorkItems => CopyClientLogger.Info|Get Work Items ClientCopyCore|ExecutingProcess.UpdateWorkItems => WebServiceConnector.GetWorkItems => CopyClientLogger.Info|Work Items - Id=-34,StatusIcon=PendingAction,StatusText=,UncPath=\\L2-JAJA-WS10-01\D$\MigrationTest\12-08\carol_st_clair_000_1_1_1.pst,Locked=False,WorkTypes=DisplayAction, Id=-33,StatusIcon=PendingAction,StatusText=,UncPath=\\L2-JAJA-WS10-01\D$\MigrationTest\12-08\bill_rapp_000_1_1.pst,Locked=False,WorkTypes=DisplayAction, Id=-32,StatusIcon=PendingAction,StatusText=,UncPath=\\L2-JAJA-WS10-01\D$\MigrationTest\12-08\albert_meyers_000_1_1.pst,Locked=False,WorkTypes=DisplayAction,
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center