Monday, September 23, 2013

Powershell Rename-Computer and Add-Computer firewall -- non-domain joined machine

Had a challenge today where I needed to join a bunch of machines to our domain (a bunch of cloned VMs to be exact). I found I could do this through a pretty simple powershell script as follows.

$credlocal = get-credential
$creddomain = get-credential

$machinelist = import-csv c:\temp\machines.csv

foreach($line in $machinelist)
{
 
    add-computer -computername $line.IP -localcredential $credlocal -domain my.domain -domaincredential $creddomain -Newname $line.Hostname -restart

}
Where machines.csv is a CSV file with Hostname/IP pairs and a header row. It prompts for credentials twice, once for the local/built-in admin, then one with domain-join permission

However, when I actually tried to run this I got the following error.

add-computer : Cannot establish the WMI connection to the computer 'xxx.xxx.xxx.xxx' with the following error
message: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)). 
At C:\temp\renamecomputer.ps1:8 char:5
+     add-computer -newname $line.Hostname -computername $line.IP -localcredent ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (xxx.xxx.xxx.xxx:String) [Rename-Computer], InvalidOperationException
    + FullyQualifiedErrorId : RenameComputerException,Microsoft.PowerShell.Commands.RenameComputerCommand
This error was pretty simple, because these machines are not domain joined, the $c/$admin/etc shares are not enabled. You can enable the pretty simply see here:

http://everydaynerd.com/how-to/fix/windows-7-enable-admin-share

After that though, I was getting:

 add-computer : Cannot establish the WMI connection to the computer 'xxx.xxx.xxx.xxx' with the following error
message: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA).
At C:\temp\renamecomputer.ps1:8 char:5
+     add-computer -newname $line.Hostname -computername $line.IP -localcredent ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (xxx.xxx.xxx.xxx:String) [Rename-Computer], InvalidOperationException
    + FullyQualifiedErrorId : RenameComputerException,Microsoft.PowerShell.Commands.RenameComputerCommand
This error turned out to be less straight-forward to fix. The short version is, you have to allow RPC calls through the firewall (something AD does automatically, either by design or by settings that have been in our domain long before I started working here) which isn't really easy because of Asynchronous callback. Basically, all incoming RPC calls go to port 135, no problem, you can open that. But so that calls don't tie up that port, all the first request returns is a new port for all future calls to come in on - this is more problematic because this appears to be ANY non-standard port; you can't very well open the firewall to all ports about 5000. Also, all of the remote-management rules that are in advfirewall (disabled) don't see to have any effect on this problem. Luckily after some digging, I found you can use program-based firewall rules to get things going.

This is article is for windows 8.1 embeded, so step #2 doesn't work on win 7, but everything else seems to run. Also, step #1 is the same reg key created from the last link.

http://msdn.microsoft.com/en-us/library/jj980508(v=winembedded.81).aspx

I re-ran the command after each step, mine started working after step 5, so I think that's the key rule, but the others don't seem to hurt. Of course, this is something that has to be in the master image, so now I have reclone about 50 VMs but hey, testing things like this before the cloning is overrated.




Wednesday, September 18, 2013

ICA Connection request denied because AutoLogon was not possible and EnforceAutoLogon is active

This is what I spent my morning doing.

So in the ongoing quest to get a XenDesktop 7 environment going. I was having a problem where, when logging in as a non-admin user, the desktop would appear for a split-second -- you could just make out the windows login screen -- before kicking the user back to the XenDesktop login (Wyse Xenith 2 login, in this case).

The only Error in the event log, the one that makes this posts title, was as follows

  • Error | ICA Service | EventID: 34 | ICA Connection Request denied because AutoLogon was not possible and EnforceAutoLogon is active.
Googleing this error code returned nothing, 0 results. Googleing the symptoms returns some things, but nothing that solved my problem.

In my case it was simple and stupid. I had put these new machines in an old OU in AD. This OU had, unbeknownst to me, a GPO which denied local login to non-admins (OU was for remote-desktop machines in the past). Removing the GPO fixed everything, go figure. 

If this isn't the case in your situation, the error so far as I can tell, is caused when the pass-through authentication fails. This can be caused by any number of things (like bad GPOs), and there's a lot of good support forum posts about the non-stupid causes of this problem, so I won't go into much detail here. But here's some things I researched that might get you pointed in the right direction.

XenDesktop Passthrough Authentication failure:

Exact symptoms I described, but with a different cause:

Tuesday, September 17, 2013

Windows RDS (Terminal Server) - Stuck Applying group policy

Had a lovely time yesterday when the terminal server (2008 R2 running RDS) that our users use to access programs/files from off site decided to tank. Luckily we have a backup server... except that one was tanking as well.

The short version is that, at some point over the weekend, the server began taking inordinate amounts of time applying group policy settings, making user log on take upwards of 5 minutes and killing server performance. Some of the error available in event viewer included

  • warning|grouppolicy|eventid:1090|"Windows failed to record Resultant Set of Policy (RSoP) information, which describes the scope of Group Policy objects applied to the computer or user. This could be caused by Windows Management Instrumentation (WMI) service being disabled, stopped, or other WMI errors. Group Policy settings successfully applied to the computer or user; however, management tools may not report accurately."
  • warning|winlogon|eventid:6005|"The winlogon notification subscriber <GPClient> is taking long time to handle the notification event (CreateSession)."
  • warning|winlogon|eventid:6006|"The winlogon notification subscriber <GPClient> took xxx second(s) to handle the notification event (Logon)."
On the user side you would see "Applying user Policy..." for 5+ minutes while trying to login. When I tried to reboot one of the servers it took (quite literally) several hours to get past the "Applying computer settings" screen. On reboot, in task manager you'd see an svchost process using 2+GB of ram and 100% cpu (limited to one core, so it was ~13% in my case). Killing this process would cause all sorts of interesting errors to occur - best I can tell this was the GPclient service. 

After a few hours of trying different things - notably de-joining  from the domain, which didn't work and took forever - I finally figured out it had something to do with the WMI repository. From command line I tried:
winmgmt /verifyrepository
winmgmt /salvagerepository
Neither of these ever returned anything (let them both run, separately, for 30 minutes).  While either was running there would be a winmgmt.exe process in task manager using 100%/13% CPU and progressively more RAM. So, since neither of those worked I tried:
winmgmt /resetrepository
Boom! Everything was back to normal. It was almost disconcerting how quickly everything started working again. Rebooted the server and it shutdown and restarted in its normal couple of minutes. I have yet to discover exactly what caused the wmi repository to corrupt but at least for the time being users are able to get to their stuff.
 

Wyse Xenith 2 - Unable to set up connection (err=-5914)

This error, which I mentioned in the post just minutes ago, turned out to be a pretty simple fix. As I also mentioned in the last post, I'm building up a XenDesktop 7 environment to replace our current XenDesktop 5.6 Environment, and I'm trying to document all of the things that I figure out somewhere where other people might benefit from them.

Anyway, like I said, this fix was pretty simple. The error I was getting (This is in the Event Log of the Wyse Xenith 2 client) was :


  • xx:xx:xx Error ERR_TCP_CONNECT_ERROR
  • xx:xx:xx SSL: Unable to setup connection (err=-5914)
The error displayed user side was simply "Citrix Sign on Failed"

Turns out this is because of a change to the way XenDesktop handles connections, you have to specifically point the Xenith units to the "legacy" URL.

Previously my Xen.ini file looked like this, and this worked fine in XenDesktop 5.6:
pnliteserver=MYDDC.domain  
However, in XenDesktop 7 it needs to be this:
pnliteserver=http://MYDDC.domain/Citrix/Store/PNAgent/config.xml
This URL is defined in the Citrix StoreFront under StoreFront > Stores > Configure Legacy Support. There's a checkbox (enable legacy support) there as well that you'll want to make sure is checked.

After I made that change to the Xen.ini file I was able to connect to the Desktop.

XenDesktop 7 - No Desktops Available

Working on building a XenDesktop 7 deployment to replace our current XenDesktop 5.6 instance. The Controller, XMLBroker,WebStore, and pretty much every component is installed on the same (albeit beefy) server - This deployment isn't big enough to warrant separate servers for everything, just a bunch of Wyse Xenith2 thin clients.

Anyway, I got to configuring the storefront which thankfully seems a lot more straight forward than the web interface in 5.6, except one problem - whenever I log in no I get a message saying "no applications or desktops are currently available to you". I can see in Studio that there should be desktops available, but I don't get them as an option anywhere I log in. 

A few hours of googling around and going through event viewer leads me to the conclusion that there's a problem with the XML Broker Service. I have the following errors in Event Viewer:

  • Warning:Citrix Broker Service: EventID:2010: General "The Citrix Broker Service encountered a problem while an XML service attempted to listen for http(s) requests. The Windows HTTP configuration might be incomplete or incorrect. ": Details Access is Denied System.Net.HttpListenerException
  • Error:Citrix Store Service:EventID:4003: "All the Citrix XML Services configured for the farm Controller failed to respond to this XML Service transaction"
  • Error:Citrix Store Service:EventID:0 : "An error occurred while attempting to connect to the server <this.stupid.server> on port <xxxx>. Verify that the Citrix XML Service is running and is using the correct port. If the XML Service is configured to share ports with Microsoft Internet Information Services (IIS), verify that IIS is running. This message was reported from the XML Service at address . The specified Citrix XML Service could not be contacted and has been temporarily removed from the list of active services."
The long and short of these is : "The XML service didn't start correctly and so the Store Front is failing to connect to it so storefront can't determine what desktops are available". The Details of the first error are useful, because - my knowledge of port binding is limited, but generally sufficient - it suggested that whatever port the XML service is trying to bind to is already in use.

This information leads me to this post on the Citrix forums: 


Which suggests changing the http port for the Broker Service. This is done via the command:

This is in the citrix install directory, typically c:\program files\citrix
..\citrix\broker\service\brokerservice.exe -wiport xxxx
I did this, but unfortunately the errors continued. Then I ran the following command and it showed a number of other ports that the XML service is using:

..\service\brokerservice.exe /show
SDK Port: 80
VDA Port: 80
WI Port: 8888
WI SSL Port: 443
Changing all of these ports got the broker service up and running.

The Broker Service automatically restarts itself when you run these commands
 ..\brokerservice.exe -wisslport xxxa
..\brokerservice.exe -sdkport xxxb
..\brokerservice.exe -vdaport xxxc 
At first I changed all four of these, and that caused the desktops to start showing up (After I changed the port of the Delivery controller in StoreFront (StoreFront>Stores>Manage Delivery Controllers).

Unfortunately it also caused all the desktops to unregister from the controller and Studio to break. This is because the vdaport appears to control what port the desktops need to register with and the sdkport controls port the Studio needs to connect on (as well as probably any other management software). Changing those two things back to port 80 things started working more the way I'd expected.

I have yet to actually get a thin to connect -- getting "SSL: unable to setup connection, (err=-5914)" but more on that once I figure it out.