[FIXED] Citrix XML Service Issue after fresh XenApp 6.5 install

January 6, 2012


I came across this issue recently when deploying a new Citrix XenApp 6.5 farm on Windows Server 2008 R2 and just wanted to make a quick note in case anyone else runs into it!


The Citrix XML service was not working on the first server in a new Citrix XenApp 6.5 farm I was building. When connecting to http://localhost/Scripts/ctxsta.dll in a browser I was receiving the following error:

HTTP Error 500.0 – Internal Server Error
There is a problem with the resource you are looking for, so it cannot be displayed.


Module IsapiModule
Notification ExecuteRequestHandler
Handler ISAPI-dll
Error Code 0×80070002


It appears that for some reason, the resource folder had not been copied into the C:\inetpub\Scripts directory by the XenApp 6.5 installer.

To fix I simply copied the resource folder from C:\Program Files (x86)\Citrix\system32\ to C:\inetpub\Scripts\

Once copied I restarted IIS by typing iisreset in a command prompt.

You should now receive the following message when connecting to http://localhost/Scripts/ctxsta.dll which shows that the Citrix XML service is working correctly:

HTTP Error 405.0 – method not supported
The page you are looking for cannot be displayed because an invalid method (HTTP verb) is being used.


Module IsapiModule
Notification ExecuteRequestHandler
Handler ISAPI-dll
Error Code 0×00000000



[FIXED] Google Chrome user settings with roaming profiles and environmental variables

November 1, 2011


Google Chrome is fast becoming popular in the enterprise and Google has provided some tools to make deployment and management easier for Windows admins:


By default, Google Chrome keeps user settings in the following locations:

Windows XP/2003:

C:\Documents and Settings\<username>\Local Settings\Application Data\Google\Chrome\User Data\Default

Windows Vista/2008 & 7/2008 R2:

C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default

Unfortunately, due to the fact that Google Chrome keeps user settings in the local application data section of the user profile, it cannot be used with roaming profiles out of the box. For some enterprises, this may be a major road block in deploying Chrome!

Google’s Group Policy templates allow for setting the UserDataDir to another location however unfortunately, if an environmental variable (such as %APPDATA%) is used within the UserDataDir path (ie %APPDATA%\Google\Chrome\User Data), Chrome crashes on startup. It appears that Chrome does not support the use of environmental variables for passing paths via GPO.


Google seem to have created their own variables rather than using the standard Windows environmental variables.

The current list of Chrome variables on Windows includes:

  • %APPDATA% = ${roaming_app_data}
  • %LOCALAPPDATA% = ${local_app_data}
  • %USERNAME% =  ${user_name}
  • %COMPUTERNAME% = ${machine_name}
  • %USERPROFILE% = ${profile}
  • %PROGRAMFILES% =  ${program_files}
  • %WINDIR% =  ${windows}

Other variables:

  • ${documents} – The “Documents” folder for the current user. (“C:\Users\Administrator\Documents”)
  • ${global_app_data} – The system-wide Application Data folder. (“C:\AppData”)

So for example, to store Chrome’s user data in the roaming application data section of users profiles, I set the UserDataDir policy path to:

${roaming_app_data}\Google\Chrome\User Data

[FIXED] Backup Exec 2010: e000848c – Unable to attach to a resource. Make sure that all selected resources exist and are online, and then try again. If the server or resource no longer exists, remove it from the selection list.

October 24, 2011


Backup Exec 2010 R3 was failing to perform a single item (GRT) restore to an Exchange 2007 server from either disk or tape (Client is using B2D2T). Both the Backup Exec Media server and Exchange 2007 server were running Windows Server 2008 R2.

The error being displayed was:

Error : e000848c – Unable to attach to a resource. Make sure that all selected resources exist and are online, and then try again. If the server or resource no longer exists, remove it from the selection list. Edit the selection list properties, click the View Selection D


I checked all the usual suspects and all account permissions, services (Exchange System Attendant) etc were set and running OK.

In the end, I had to modify the hosts file on the Exchange 2007 server with the following:                   hostname of the Exchange server                   FQDN of the Exchange server
actual IPv4 address    hostname of the Exchange server
actual IPv4 address    FQDN of the Exchange server

Once done, I restarted the Backup Exec Remote Agent for Windows Systems service on the Exchange server.

Official Symantec article: http://www.symantec.com/docs/TECH75728

Creating a Self-Signed Certificate on Windows Server 2008/2008 R2 without IIS

October 13, 2011


Often I deploy wireless networks with 802.1X PEAP authentication into Windows Active Directory environments which do not have an existing Enterprise Root Certificate Authority (CA). In environments where there are no further requirements for an Enterprise Root CA, I prefer the simplicity of using self-signed certificates on Windows 2008/2008 R2 based RADIUS servers running Network Policy Server (NPS). These servers are generally Active Directory domain controllers.

Note: Enterprise Root CA services need to be designed and implemented properly rather than simply installed on a whim to generate a certificate!


So the problem is that it is not possible to generate a self-signed certificate on Windows Server 2008/2008 R2 without installing IIS 7.0 (do you really want IIS on your DCs?) or OpenSSL.


Back in IIS6 we had a tool called SelfSSL to generate and assign self-signed certificates. SelfSSL is bunded with Microsoft’s IIS 6.0 Resource Kit Tools

SelfSSL is technically not compatible with IIS 7.0 however I have discovered that we can still use it to generate a self-signed certificate on newer servers!

Download and install SelfSSL (do not bother selecting any other components of the IIS 6.0 Resource Kit Tools)

Launch SelfSSL by going to Start >Programs > IIS Resources > SelfSSL > SelfSSL (Note: You must run SelfSSL elevated as an Administrator, thanks to Nick for clarifying below!)

selfssl.exe /N:CN=fqdn.of.radius.server /K:1024 /V:1825

The above command will generate a new certificate with a key length of 1024 and a validity period of 5 years (1825 days).

When prompted to overwrite the settings for site 1, answer with yes. An error opening the metabase will appear but can be ignored due to IIS 6.0 not being installed on the server.

You will now be able to find the certificate in the local computer certificate store ready for use in your NPS policies or export to other servers/devices!

[FIXED] Citrix Printing issue: Windows cannot print due to a problem with the current printer setup

September 6, 2011

Just wanted to make a note of this one!

Basically, some users on a XenApp 5/Windows Server 2008 farm couldn’t print from Office 2007 programs and received an error “Windows cannot print due to a problem with the current printer setup”

The error is caused due to a bug in Windows Server 2008 which does not allow more than a 100 print queues (often Citrix servers will exceed this with mapped client printers etc).

Discussion: http://forums.citrix.com/thread.jspa?threadID=256687&start=30&tstart=0

Hotfix: http://support.microsoft.com/kb/2532459

WSUS clients not showing up in the WSUS console.

June 1, 2011

I’ve had this problem twice over the past couple of years and each time it took me a little while to figure out… Basically some Windows computers that have been deployed via methods such as WDS or imaged based cloning do not show up in the WSUS console, even though they receive updates without issue. The issue is that the computers all have the same SusClientId.

The  key to fixing this issue is to delete the SusClientId, PingId and and AccountDomainSid from the Registry, allowing the Windows Update Agent to automatically generate a new one.

Once this is done, re-register the computer with the WSUS server using wuauclt /resetauthorization /detectnow

I’ve found a good article explaining the process and providing some example scripts here: http://msmvps.com/blogs/athif/archive/2005/09/04/65174.aspx

Also check the WSUS Support Team Blog: http://blogs.technet.com/b/sus/archive/2009/05/05/resolving-the-duplicate-susclientid-issue-or-why-don-t-all-my-clients-show-up-in-the-wsus-console.aspx

[FIXED] XDR-Fixup issue during Active Directory Domain Rename

April 14, 2011


I recently performed an Active Directory domain rename for a client with a Windows Server 2003 functional level domain/forest and Exchange 2003 messaging environment. The client had a single label DNS domain name and needed to move to a proper 2 part DNS domain name for software compatibility reasons. Unfortunately, despite significant planning being put into the project, we ran across an issue with the XDR-Fixup tool during implementation of the domain rename which stopped us in our tracks.

For reference, several excellent articles documenting the domain rename process are available:


The issue we had came when we went to run the XDR-Fixup tool to modify the Exchange server attributes in Active Directory, after completing the domain rename itself, which was successful. The following command was run from the domainrename directory:

XDR-fixup /s:domainlist-save.xml /e:domainlist.xml /trace:tracefile /changes:changescript.ldf /restore:restorescript.ldf

We received the following error:

Operation failed:

No other details were displayed. The changescript.ldf file did not end up being created. The restorescript.ldf file is created but at 0kb with no content.

The tracefile did not show any obvious signs of why the process had errored out.


The cause of this problem was that some NTDS objects had been removed to the LostAndFoundConfig container in the Configuration partition of Active Directory. For some reason, when orphaned objects are in this container, the XDR-Fixup process is unable to complete successfully.

The solution to this issue was to deny access to any objects in the LostAndFoundConfig container for both the Domain Users and Domain Computers groups.

This can be done as follows:

  1. On a domain controller, run adsiedit.msc
  2. Add Configuration partition to this tool.
  3. Expand it, and locate the CN=LostAndFoundConfig folder to see if there is anything in it, if yes,
    • Select each object in this container
    • View its properties,
    • In security tab, click “Add…”, to add Domain Users and Domain Computers groups into list and Deny them “Full Control
  4. Then, try XDR-Fixup again.

Thanks to Microsoft support for this fix!

[FIXED] Windows Mobile 6.5 device will only sync over WiFi, not 3G/NextG

November 9, 2010


I came across this issue today on a Telstra branded HTC HD2 running Windows Mobile 6.5 connected via Telstra NextG. I also had this exact same issue a year ago on a HTC Snap, also connected via Telstra NextG and wish I’d blogged it back then – it would have saved me a lot of time!


I’m not sure if this is just a bug on some Telstra HTC Windows Mobile devices but when using Microsoft Exchange ActiveSync to synchronise with an Exchange server, the Windows Mobile devices listed above would only synchronise over a WiFi connection. With the WiFi connection disabled or not in use, the devices were unable to synchronise using the Telstra NextG connection and would sit there saying “Synchronizing”. No error was displayed.

It appears that for some reason, these devices do not set the connection to be used by the ActiveSync program, instead leaving the option blank. This means that Exchange ActiveSync never tries to use the 3G data connection if the WiFi is unavailable.


Step 1

The first part of this solution is to set the device to use the Providers “Internet” connection, even when connecting to a “private network”. This is necessary because these particular devices will always revert to using this connection rather than the default Internet one.

Go to Start > Settings.

Select the Menu button at the bottom right and then choose All Settings.

Select Connections.

Select Connections again.

Select the Advanced tab at the bottom of the screen.

Select the Select Networks button.

Ensure that the option Programs that automatically connect to a private network should connect using: is set to your providers internet connection, such as Telstra Internet

Step 2

Now the Microsoft Exchange ActiveSync server connection needs to be set to use this internet connection.

To setup the connection, go to Start > Tools > ActiveSync

Select the Menu button and either add a new server source or select Configure Server… to edit your existing ActiveSync connection.

Press Next through the settings screens until you get to the screen titled “Edit Server Settings”.

Select the Menu button at the bottom of the screen and select Advanced.

Select a connection to be used by ActiveSync, normally this will be Dedicated. If Internet is selected, from my experence the device may default back to Dedicated anyway.

You should now be able to synchronise your Windows Mobile using Exchange ActiveSync over 3G!

Exchange 2007 to 2010 Migration: Public Folder Issue Fix

September 7, 2010


I recently came across the following issue while performing an Exchange 2007 to Exchange 2010 migration for a company that still heavily utilised mail-enabled public folders. The client’s Exchange environment was quite old and had been previously migrated from Exchange 5.5 to 2003 and hadn’t been properly decomissioned with the original move to 2007, but that’s another story!


The issue I had was that once I moved all receive connectors to the new Exchange 2010 server, emails sent to any of the mail-enabled public folders (which were still being replicated between the 2 servers) was being rejected with the following NDR:

#< #5.2.0 smtp;554 5.2.0 STOREDRV.Deliver.Exception:ObjectNotFoundException; Failed to process message due to a permanent exception with message The Active Directory user wasn’t found. ObjectNotFoundException: The Active Directory user wasn’t found.> #SMTP#

The following error was found in Event Viewer:

Log Name:      Application
Source:        MSExchange Store Driver
Date:          7/09/2010 2:00:02 AM
Event ID:      1020
Task Category: MSExchangeStoreDriver
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      server@domain
The store driver couldn’t deliver the public folder replication message “Folder Content (PublicFolderDatabase@domain)” because the following error occurred: The Active Directory user wasn’t found.


Given this Exchange environment was originally running versions prior to Exchange 2007, the legacy Administrative Group and all its empty subcontainers still existed. An explanation from the Microsoft Exchange Team of why this issue occurs can be found here: http://msexchangeteam.com/archive/2010/05/05/454821.aspx

The solution to this issue was to delete the empty Servers container from the legacy Administrative Group.

Using ADSIEdit.msc, connect to a domain controller and navigate to:

CN=Configuration , CN=Services, CN=Microsoft Exchange, CN=[ExchangeOrganisationName], CN=Administrative Groups, CN=[LegacyAdministrativeGroupName], CN=Servers.

Right click the Servers container and select Delete

Click Yes

Mail should immediately starting flowing into your mail-enabled public folders.

UPDATE 25/10/2011

I recently ran into Public Folder replication issues at a client who had moved from Exchange 2003 -> Exchange 2010 that appear to have the same  root cause as the above. Once all Exchange 2003 servers had been decommissioned, Public Folder replication failed to occur between any of the new Exchange 2010 servers (some of which were added after the decommissioning of Exchange 2003). Absolutely NO Public Folder errors were logged in the Event Logs of any of the servers whatsoever, even with all logging set to Expert level.

On a whim, I deleted the Servers container from the legacy Administrative Group. Public Folder replication started working immediately!

ODBC System DSN Data Sources Failing to Display

September 7, 2010


Today I ran into an issue at a client where new System DSNs were failing to display in the ODBC Data Source Administrator on a Windows Server 2003 server.


After creating a new System DSN, the DSN would display in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI however would not be visible in the ODBC Data Source Administrator or available to use by any other ODBC aware application.


The fix was to delete the default Registry key at:


  1. Right-click the key called ‘ (Default) ‘ and select Delete.
  2. If unable to delete the key, double-click the key and erase the Data value entered. Once done, the value should read ‘ (value not set) ‘.

MSKB available here: http://support.microsoft.com/kb/2000277

Powered by Wordpress and MySQL. Theme by Shlomi Noach, openark.org