Recently we have published a new version of the Client Support Tool (CST) available for download through the SDN. This version supports both Duet 1.0 (SP2 and above) and Duet 1.5 Preview clients.
In this blog I will demonstrate how to take advantage of the new features by following several troubleshooting scenarios.
A Missing Application – Using the Enhanced “Cache Viewer”
Let’s say that although Leave Management Scenario was installed on the server side, one of the users is missing the option of creating new “Leave Request” in Outlook. To troubleshoot this, we can use the “Cache Viewer” feature which displays three cache types that the client holds:
- “Service Provider” – shows the cached Xamls (UI components)
- “Reference Cache” – shows the cached web services responses
- “Offline IBF Metadata and Files” – shows the local metadata scopes which were downloaded from Duet Read Service
The first thing we should do is to check if the application’s scopes exist on the client. Let’s start by right clicking on the CST icon on the system tray and choose “View Client Cache”:
This will open the “Cache Viewer”. In order to view the downloaded applications scopes use the “Offline IBF Metadata and Files” tab:
By looking at the available scopes you will notice that the “Leave Management” application scopes are missing. (If the list was empty, this means that no metadata was downloaded to the client from Duet Read Service. To investigate this you can use the event viewer logs).
There are several reasons for a missing scope:
- The user is not assigned to the appropriate content group (Duet 1.5) or role (Duet 1.0)
- The client does not hold the most recent metadata
- The application is not deployed\configured correctly on the server side.
In Duet 1.5 clients, we can use the “Cache Viewer” to eliminate the second option and to verify that the client has the most up-to-date metadata; by using the “Service Provider” tab and clicking on “Time Stamps” – both Duet client and Duet server will be queried for their metadata and Xamls timestamps:
So in our case the user’s client holds an older version of the metadata. To get the new metadata you should wait for the cache refresh interval as defined in the group policy. It is also possible to retrieve the new metadata by using the “Clear Metadata and Files Cache” option to delete the current metadata, then use the “Reset Deployment Key” option (both are under Client Maintenance menu) to force the client to redeploy on the next run, and finally restart Duet utility. These actions will cause the client to fetch the latest metadata from Duet Read Service.
* Please note that in Duet 1.0 resetting the deployment key might switch the client to secondary mode. This will require Microsoft Promote Machine tool (available on Duet CD) to restore the client to primary mode (once the tool exists on the client, it is possible to run it from the CST menu instead from command line).
If after these actions the metadata timestamps still differ, then this might indicate that the latest metadata was not published successfully to the Microsoft Metadata Service. You should check the applications log in the J2ee and consider to manualy republish the metadata.
In our troubleshooting scenario, after performing these actions the user got the missing leave application scopes:
To verify that the application was downloaded successfully and is in operational state, you can use the “Reference Cache” tab:
A green icon indicates the web service call was successfully stored in the client database and a warning icon indicates the web-service response has not been cached; this might indicate on a problem: during the deployment phase Duet utility tries to call and store the response for these web services. If the deployment finished and there are still missing responses, you should check the client event viewer logs or the Duet J2ee trace for more details.
By clicking on a specific call you can see the response itself, this might help when you want to verify the response contains the right values.
* Please note that while the user works with a Duet application, other web-services are called at runtime – those web services are not cached on the client database and therefore will not be shown in the “Cache Viewer”.
In our case the Leave Management scenario web-service calls were cached successfully. You can also verify that the Leave Management Xamls (the application UI components) arrived and stored in the client cache by using the “Service Provider” tab and checking that the Xamls exists:
By looking at these values we can be sure that the UI components exist. All that is left to do is to run Outlook and verify the application works: