So here are some quick lessons I learned recently in some of the Citrix Provisioning XenDesktop vSphere environments I have been working in. The typical solution consists of Citrix Provisioning Services streaming down a XenDesktop brokered OS to a vCenter managed vSphere Virtual Machine. Lots of ties and connections to different systems and management consoles and different Admin groups sometimes.
The first time, I was working with the VMware servers and during some housekeeping, I decided to remove a HOST from vCenter and add it back in under a different cluster. The VMs on the box all remained up and on and weren’t changed. What I forget about was the XenDesktop management interface that was linked to the VMs via vCenter to facilitate power operations. When the host and it’s machines were added back into vCenter, XenDesktop could no longer recognize them. The associate between Virtual Machine and Active Directory computer account was broken and had to painstakingly be reestablished. Woops.
The next time around, I was working with the Provisioning Services console and due to some flaky behavior, decided to recreate some AD accounts for the XenDesktops. Again, forgetting about the management in XenDesktop, I had broken all of the connections between Virtual Machine and AD Computer account. This time, the Virtual Machine column was intact but the AD column just had old unresolvable SIDs in it. Back to the console to reestablish all of the connections again.
In environments where Active Directory, XenDesktops and VMware are handled by different teams, it is prudent to try to get on the same page. With all the connections and dependencies, seemingly innocent actions in one environment could create disastrous results in another.
I actually could not think of a way to help locate this machine given the above criteria short of heading into the switches and looking for MAC addresses and switch ports. Something entirely out of my wheelhouse. What my friend SMAlan* did remind me of, was the need for Virtual Machine management and processes. Super easy to create VMs and even easier to lose track of them. Even easier to forget about virus protection and backups and other protective measures we’ve spent years developing for our physical servers.
Sam Jacobs sent over a quick best practice note reminding us verify that our STA IDs begin with the letters ‘STA’ for XenApp Plug-in Version 12.0 compatibility. The following CTX article details how Published Applications will fail to start if the STAs do not start with this naming convention. 
Citrix Provisioning Services is no different. Here are two quick items to check when your Domain doesn’t seem to want to trust you anymore. 
For a while now, we have been recommending using XenDesktop for users to get back to their Physical Desktops back in the office as a type of localized GoToMyPC. The solution was especially appealing to existing XenApp customers that were publishing RDP session on their XenApp farms as a way of providing secured access to user’s PCs. RDP over ICA provided it’s own challenges (video, sounds etc.) so ICA all the way back to the Physical Desktops was a winner. As long as they were using XP. Recently, I tried to implement this solution for a client that was running Windows 7 on their desktops. A typical workstation with a couple of monitors and Windows 7 OS.
Sure you can use WebEx or GotoMeeting but you want something FREE! Try out 
While working with the newest versions of Windows 2008 R2 and Windows 7, I am beginning to notice more and more compatibility issues with Multi-Monitors and 