Debugging RES Workspace Manager
Debugging RES Workspace Manager
This blog will show you how to enable debugging in RES Workspace Manager and how to determine what is happening with your users workspace. Debugging will give more indepth knowledge of what is happening, it shows what is going on below the surface.
Setting up debugging
Debugging with RES Workspace Manager is done with a few register entries to start with.
To enabled debugging the following entries have to be added to the registry on each server or workstation that you need debugging.
- TRACE – REG_SZ – Value: Yes
- TRACEDETAILED – REG_SZ – Value: Yes
- TRACEFILE – REG_SZ – Value: location and file name of the log file
There is another settings for the size of the file but in most cases that isn’t being used… at least I’m not using it for I will remove all tracing stuff before I close down. Users tomorrow want a fast environment and debugging isn’t helping with that.
So after setting the register part I created the C:Temp folder to make sure the log file can be created. The log file won’t be created without the folder being there. It won’t create the folder itself.
After you finished doing this, you open the services console and restart the RES Workspace Manager service. Or like I do you create a little reg file adding these entries and a command file creating the directory and restarting the service called RES.
After this, when you look into the folder you will see that a log file is created and is being filled.
RES support uses a tool called RESPTraceView, not sure if that’s available for anyone, if I get word it is, I’ll post a link to it here.
When a user logs on all actions are registered in the log file, you can open it with Notepad and when it grows bigger perhaps better with wordpad. It might be handy to have an editor that allows for filtering so that you can filter out the user name of the user you are looking for.
The log shows a lot of details, not all of them are clear to me at this moment.. but the main thing is that you can enable this logging and call in RES support to take a look at them. Sometimes the error is clear but often it’s not.
My current issue
Before I wrote this blog I was debugging an environment that all of a sudden, or so it seems, has become slow. We have no clue on why it’s behaving like this but in the logs we noticed that it was looking for a Citrix ICA Client directory. We don’t need a Citrix client on the server so there was none.
We installed the Citrix receiver and so the error went away.
Further on we noticed that RES was doing an IMA check to determine if it was a Citrix server but IMA has been replaced with FMA so that one was doomed to fail.
I don’t think my issue has anything to do with the lack of support for XenDesktop 7, if you look in the logs it takes a mere few seconds to find out there is no IMA and it continues.
The Citrix check and so takes a little time so the other actions around it take all the other seconds from the user. I have been testing and at one point I was able to logon quickly , the log however showed the same action only with a shorter time frame.
Steps I’ve taken so far
I’ve disabled every module in the console to see if it’s a certain configuration that is doing this, disabling didn’t do anything although at first it seemed that the printer module was the culprit. After disabling that one the user with issue logged on fast.. trying the same again later on didn’t provide the same result.
I cleared all user settings for the user but also that didn’t help making it faster…
I checked all permissions on the applications so that only application groups are present and no loose users exist. This also didn’t help the case.
Right now I’m on a dead end or like we say in The Netherlands (22 medals at the Olympics ) standing in a forest looking at the trees wondering where to go 🙂
Will debug on and keep you posted