Earlier this week I was asked to investigate a problem with the Xerox Universal Printer Driver. Users complained that printing to a Xerox printer was much slower than printing to an HP printer.

I received a reference document from a user, a rather complex Excel sheet. When selecting multiple tabs it took almost a minute to generate a print preview in Excel 2007 running on Windows 2003 with XenApp 5.

I was aware of a bug in the Xerox Universal Driver where almost 9.000 files were copied into the user’s profile directory (I wrote about that in an earlier post). But this seemed to be another problem.

(more…)

Today I troubleshooted an old DOS application that needed to run on a 32 bit Citrix XenApp Server. The last time I saw an actual DOS application in a production environment must be years ago.

When starting the application, the WOW subsystem (NTVDM) crashed with the message: “NTVM encountered a hard error.”:

After spending some time troubleshooting I remembered a similar issue from a few years ago where a DOS application worked fine from the Console but refused to work from an RDP or ICA session.

(more…)

A while ago I was invited for a presentation at the UK Citrix User Group. I went there together with my colleague Ingmar Verheij and we had a great day there.

I was impressed with what I say there, a community that was very much alive and with good discussions. It was clear that the UK Citrix User Group was doing very well, thumbs up for their Steering Group!

So Ingmar and I wondered why there was no active Dutch Citrix User Group in The Netherlands. There had been an initiative in the past, the DUCUG so we decided to see if we could revive it.

(more…)

I was deploying virtualized Citrix XenApp Servers on HP BL460c G6 servers and somehow the storage (direct attached) responded very slowly.

I had expected reduced performance (see my earlier post) since I didn’t have the  Battery Backed Write Cache module installed.
I did order them but had to start deployment before they arrived.

I did not however expect such an extreme bad performance. Deployment took ages or sometimes failed completely and when logging in to a VM it responded very sluggish.

Disk Latency

I looked in the vSphere console what the Disk Latency was. Latency under 10ms is usually considered good while a latency between 10 and 20ms is a potential performance problem.

I was shocked to notice that the Disk Latency was much higher with peaks toward 2.000 ms (2 seconds!):

(more…)

I was working on an unattended installation of Citrix Presentation Server 4.5 or rather Citrix Xenapp. I was creating the dsn file for the installation by a script that uses the echo command and output this to a file.

This is a part of the script:

rem Create ODBC file
rem ———————————————————————–
echo [ODBC] > %ODBC%
echo DRIVER=SQL SERVER >> %ODBC%
echo UID=%SQL_SA% >> %ODBC%
echo Address=%SQL_SERVER%,1433 >> %ODBC%
echo Network=DBMSSOCN >> %ODBC%
echo LANGUAGE=us_english >> %ODBC%
echo DATABASE=%CTX_DATASTORENAME% >> %ODBC%
rem echo WSID=%COMPUTERNAME% >> %ODBC%
echo APP=Citrix IMA >> %ODBC%
echo SERVER=%SQL_SERVER% >> %ODBC%
echo Description=Citrix Datastore >> %ODBC%
echo. >> %ODBC%

Even though the generated DSN file looks ok the installation fails. If you look in the installation log you can see this error: Error 26009. Could not Access the datastore using the DSN file.

I then created a dsn file through the ODBC Data Source Administrator and then the installation went ok. I compared the DSN file with the one my script generated and it was the same.

A search with Google and in the Citrix forums leads to numerous posts with the same error but none with a real solution. Some suggestions are that you need to remove the WSID line or even the order of the entries in the DSN file. But none of these suggestions work.

So I compared the two files again and I noticed that the filesize of my generated DSN was slightly bigger. So let’s look again at the script:

echo DRIVER=SQL SERVER >> %ODBC%

See the space right before the >>? This means that after each line in the dsn file there’s a space too. If you open the file with a Hex Viewer you can easily see the spaces (ASCII value 20):

So the solution is to change this (for all lines) to:

echo DRIVER=SQL SERVER>> %ODBC%

After that it works perfectly!

If you develop an application for Terminal Server you might want to react on session events. This means that your application is notified when a user logs on, logs off or becomes idle. This can be done with the WTSWaitSystemEvent function. Implementing it is rather simple and could look something like this:

Notice that you would probably do this from a seperate thread otherwise you will block the main thread. To stop waiting for Events you send a special event:

Please note that there are at least 2 issues with this API, one with Windows 2000 and one with Windows Vista. On Windows 2000 events are reported twice for each actual event. Microsoft’s resolution?

The application should expect the event twice, and filter out the second occurrence.

Now how do we solve this? I would suggest introducing a small delay after an event trigger, this way you will probably not receive the duplicate event.

On Windows Vista there’s another issue: After you set the value of the EventMask parameter to WTS_EVENT_FLUSH in the WTSWaitSystemEvent function, no pending calls to the function return on a Windows Vista-based computer. Now what does this mean? It means that after sending WTS_EVENT_FLUSH the thread never responds! So there’s actually no nice way to end the thread, the only escape is a call to TerminateThread.

Microsoft does offer a hotfix, so my suggestion is a check on startup that will notify the user that he/she needs to install the hotfix. A version check can be done on winsta.dll, the version before the fix is 6.0.6000.16386. Hotfix version is 6.0.6000.20664. According to this article the fix will be included in Vista SP1.

References:

• BUG: WTSWaitSystemEvent Returns Terminal Services Event Twice
• After you set the value of the EventMask parameter to WTS_EVENT_FLUSH in the WTSWaitSystemEvent function, no pending calls to the function return on a Windows Vista-based computer
• Hotfixes and Security Updates included in Windows Vista Service Pack 1