We’ve had two customers impacted by this problem, so please take notice prior to upgrading or installing Vsphere 4.1 with Flex-10. Read links below for more specifics.
While onsite trying to remotely push a Backup Exec 2010 R2 remote agent, we were getting a lot of the “error code 1603” messages, which stated:
“Error connecting to the remote server. Ensure the server is available, has WMI enabled, and is not blocked by a firewall. 1603.”
It seems like this is the likely problem, mentioned in the below Symantec technote:
Our workaround was to just install the client manually on each server that wouldn’t connect, instead of going through all the steps mentioned in the above technote.
Honestly, I’m not much of an Internet Explorer fan but the new v9 beta was released. You can download your appropriate version here: http://windows.microsoft.com/en-US/internet-explorer/download/ie-9/worldwide
Let us know what you think! Is it faster/better than say Firefox or Chrome?
XenApp has for a long time had direct support for integration into Novell eDirectory environments. No so for the XenDesktop virtual desktop agent. While it is possible to integrate authentication for XenDesktop into Novell’s Domain Services for Windows this still does not provide integration of the Novell Client (used to access file and print resources) with the Citrix Virtual Desktop Agent. Further, installing the Virtual Desktop Agent on a machine with the Novell Client will revert to using the Microsoft default GINA which can have unwanted side effects.
What to do then if you need to retain the GINA from the Novell client, but also want to utilize the Citrix Virtual Desktop Agent?
Read on for a solution, to using the VDA and keeping the Novell GINA as the primary authentication for the machine. Keep in mind though that this method is unsupported by Novell, Citrix, and Microsoft.
Default Microsoft GINA
The familiar default Windows XP welcome screen. Press Ctrl-Alt-Delete to login to a standard Windows system.
To log onto windows you provide the Username, Domain and password. There is no support at this dialog to logon to anything other than standard Microsoft Windows services.
For purposes of this discussion the settings we care about are located under HKLMSoftwareMicrosoftWindows NTCurrentVersionWinLogin
Note that in the default configuration the ginaDLL key is not defined! It’s important to note that by default no ginaDLL is specified and the system utilizes some form of default module.
But, in this state we can’t easily connect to any of the Novell file or print services (Unless the Native File Access Pack is installed – but that’s another topic). To access the Novell resources we will install the Novell Client for Windows.
Install the Novell Client
Install the Novell Client for Windows as you need to for your environment and reboot the computer.
Immediately upon boot up it’s apparent that the Novell client has changed something. The familiar Microsoft Windows welcome dialog has been replaced with a Novell logo instructing the user to press CTRL-ALT-DEL.
And now the replacement of the GINA becomes truly apparent; It’s clear by this dialog that the system is a Novell Client, and options for all of the Novell specific information is provided. The "normal" Microsoft information is also available on the "Windows" tab.
Once the user provides the necessary information they are logged into the Novell eDirectory environment as well as the Windows desktop.
Pressing CTRL-ALT-DELETE within the desktop shows another dialog which has been replaced by the Novell Client. Clicking Change Password takes us to the dialog many IT departments prefer users to use to change their passwords.
Yet another modified dialog. This screen will allow the user to change both their Windows/Domain password and their Novell eDirectory password at the same time. The default Microsoft dialog only supports changing one resource (password) at a time.
For IT departments running both eDirectory and Active Directory this can be a very big issue since this dialog facilitates synchronizing the eDirectory and Active Directory passwords.
Looking at the contents of the WinLogin key, we see that the GinaDLL value has been defined as "NWGINA.DLL" – this is how the Novell client has replaced the login and change password dialogs to include support for Novell’s eDirectory.
Now, in order to access the machine through the XenDesktop DDC we must install the Virtual Desktop Agent.
Install Citrix Virtual Desktop Agent
Complete the installation of the Virtual Desktop agent as required for your environment.
Ah there’s the Rub!
After installing the XenDesktop agent the user is again greeted by the standard Windows welcome dialog.
And the standard windows Log On dialog is back as well, providing no direct method to input the Novell Connection credentials.
A second Login dialog then challenges the user for Novell credentials.
And the default Microsoft password change dialog is back as well – back to the one service at a time method of changing passwords.
What happened to the Novell GINA?
Here we see that the GinaDLL registry key now points to C:Program FilesCitrixICAServicepicaGina.dll – this has replaced the nwgina.dll which the Novell Client installed.
Assuming we want to, how do we get the Novell Gina back?
It turn out that the picaGina.dll provided by the Virtual Desktop Agent has a setting which tells it which GINA to chain to in order to process the login. Located in the CTXGinaDLL key we see that it is (by default) referencing msgina.dll.
In order to have it chain to the Novell nwgina.dll we need to update this registry key and reboot.
The updated registry key post reboot is shown.
Once the value has been changed, reboot the desktop.
Upon reboot we find that the Novell "Begin Login" dialog is back.
As is the login dialog which allows both eDirectory and Active Directory credentials to be specified.
And the Novell Change Password dialog has returned as well.
Unfortunately there is a downside to putting the Novell GINA back in place with the VDA. This comes from the fact that he picaGina passes the Microsoft credentials in the form of a UPN (user@domain) to the next GINA. The Novell GINA does not know how to process the UPN for login and as a result the user is challenged for their credentials when connecting via the VDA (no single-sign on).
Then again, without replacing the GINA, the user is challenged for their Novell eDirectory credentials anyway so it’s not really an extra challenge over what they would have had without using the Novell GINA; and their passwords are more likely to remain synchronized between the directories.
Here’s a very useful technote on how to reclaim space in a Backup Exec 2010 Deduplication folder: