Updating VMware Tools–No Reverse Imaging required!

Are you still reverse imaging to update VMware tools?! How very dark ages of you!
For anyone who deals with Citrix Provisioning Server (PVS), you have experienced first-hand how technology can make life just a little sweeter. Being able to make any change once, reboot and voila, the change is rolled out, not to mention, if you must roll-back, just another reboot and you can step back in time, ahh…
The one thing that pulls us out of that nice, happy place is when VMware releases a new set of VMware tools. In a single moment, we are snapped back to reality. What I am referring to is the fact that in the PVS world, the network card is the umbilical cord of life, providing the “C” drive to the server or desktop, interrupt the stream by attempting to update a network card driver and the stream will stop leaving you unable to ever reconnect back to it.
In the past the only answer was the extremely manual process of reverse imaging the image; a copy process that takes the image out of the PVS world and burns it onto a hard drive, allowing you to boot up the machine and update VMware tools. This works because once the machine is booted up from the hard drive, the image is no longer reliant on the network card, the stream providing the C drive. At this point, you can upgrade the tools and then reimage the disk back into PVS.
I was thinking that there must be a better way and there is! Being that the stream is physically flowing through the VMware network card and we cannot touch the card or stream, I thought, why not switch the stream temporarily to a non-VMware network card, upgrade the tools, then switch it back to the higher performing VMware card. I am happy to say that this process works great and now you can do it too! Read on for the steps on how to accomplish this.
Here is the process in detail:

1. From the PVS Console, place the image into Private Image mode.
2. Boot up the machine using this image so that changes will persist.
3. While the machine is running, go to the VMware console, edit the machine settings add in a second network card, an E1000 specifically.
a. The machine will immediately detect the newly added hardware.
b. Allow the machine to recognize the card and install the driver
4. Power down the machine.
5. Record the MAC address of the new E1000 card
6. Update the Device in the PVS Console to reflect the MAC address of the E1000 (recorded in #5)
7. Boot up the machine, quickly hit ESC to get to the Boot menu (or add in a boot delay if you’re not quick enough!)
8. Choose to boot up from the secondary card, the E1000. The machine will boot up streaming using the non-VMware card.
9. Once the machine has come up and you log in, proceed to update the VMware tools as normal. Being that the E1000 driver is a Microsoft one, the tools will update fine including the VMXNet3 driver without breaking the stream.
10. Shutdown the machine
11. Remove the E1000 network adapter from the VMware settings.
12. Update the device in the PVS Console with the original MAC address of the VMXNet3 card.
13. While the machine is booting up, hit the ESC key and enter the setup of the VM. Navigate over to the Boot menu and verify that the VMXNet3 card is listed above the Hard Drive option.
14. Boot machine normally, using the VMware (VMXNet3) card.
15. Clean up the Windows image by doing the following:
16. Open an elevated CMD prompt
17. Run the following command: SET DEVMGR_SHOW_NONPRESENT_DEVICES=1
18. Select the View menu drop-down and select the option for Show hidden devices
19. Expand the Network adapters section
20. Right-click on the E1000 and select Uninstall
21. Shut down the machine and switch vDisk back into Standard mode (Read-only)

No reverse imaging needed! Now the PVS update is complete. Bring on the VMware updates!
Enjoy!

CLEAN UP YOUR PVS SERVER (EVENTLOGS)!

Here is a quick tip I just came up with which I thought I would share.  If you are working with PVS these days, you always want to make sure that the server has as little memory of a previous life left before turning it into a vDisk. One of the things which always has stuff in it is the Eventlog.  The Eventlog used to comprise three basic logs: Application, Security and System and so it was quite easy to just right click on and choose clear for each of them. Today in a typical Windows 2008 R2 / Citrix XenApp 6.5 system, the number of logs is closer to 450!

There had to be some way to clear these up easier. Now for those (hopefully all) of you that are doing PVS with Citrix, you are probably thinking that redirecting the logs to the cache drive will be server specific and clean to start off with; yes that is true, but you don’t typically redirect all 450 of them, so the others are all stale and maybe not even contain any necessary useful information.

Enter the Windows utility, WEVTUTIL. This is a built in tool that allows you to do all sorts of interesting things with your EventLogs; we will use it to clear them all out. First off some other options that you might find useful:

To list all of the EventLogs on the System:
WEVTUTIL EL

To export a log you can use this one:
WEVTUTIL EPL System C:\Temp\System-Backup.evtx

And finally to clear out a log, use this one:
WEVTUTIL CL Application

If you want to backup and clear out the logs in one command:
WEVTUTIL CL Application /bu:C:\Temp\Application.evtx

This is all fine and good, but if you are like me and are at the point of vDisking or cloning, you probably don’t care about saving the logs and the above method will still take way too long to do 450 times, so what to do?

Why use the old trusty “For loop”!
For /F "tokens=*" %E in ('wevtutil el') do wevtutil cl "%E"

Enjoy, let me know if there is something you can add to make this better/more efficient in the comments.

Aaron

PROVISIONING SERVER AND FIREWALLS

Provisioning Server is here to stay and I think we can all agree that this is a great thing. Recently while installing a new environment I started to run into a few issues which I immediately realized was a Firewall issue. The system was configured using Windows 2008, so I immediately went to look at the configuration and like a good consultant was about to turn it off, when the client says to me, we use the Windows Firewall and it must stay on! The nerve, right? I know, I agree!

In any case, I now had to actually look into what needed to be open to make this work which doesn’t sound too difficult, look up the Citrix Doc, get the port numbers, create a rule and I’m done. Problem is that depending on what version of Provisioning Server you are using determines which ports you need to open as they changed it in 5.6 and I found references to different ports in three different documents from Citrix. In the end, there was no single document that had all of the ports listed.

Here is a nice document from Citrix (http://support.citrix.com/servlet/KbServlet/download/2389-102-648658/CitrixPorts_by_Port_0333.pdf) on ports used by Citrix Technologies, sounds pretty complete, but is definitely missing some, like 6969, which is listed on this page: http://support.citrix.com/article/CTX125744 and is used for the TSB; anyone care to guess what that one is? (no peeking!)

In order to save everyone from what I went through tracking this down, I present to you a script which when run will modify the Provisioning Server firewall with all of the ports necessary to make Provisioning Server work. It uses the NETSH (A very powerful command indeed) to add in the rules and even includes the description pulled from the various Citrix documents.

Enjoy and feel free to comment.

Aaron

@Echo Off

ECHO.
ECHO This script will modify the Firewall with rules necessary for proper Provisioning Server Communication
Echo.
Pause

netsh advfirewall firewall add rule name="Citrix (DHCP,PXE)" description="The DHCP server will offer an IP address to the target server. The DHCP server also offers other parameters, including: Option 60: PXE Client Address" protocol=UDP profile=domain,private,public dir=in localport=67,68 action=allow

netsh advfirewall firewall add rule name="Citrix (PXE Server)" description="The Target server will make a request to the PXE server for startup information. The PXE server will respond with Option 66: Boot Server Host Name Option 67: Bootfile Name" protocol=UDP profile=domain,private,public dir=in localport=67,4011 action=allow

netsh advfirewall firewall add rule name="Citrix (TFTP Server)" description="The target server will use the information sent back from the DHCP server to obtain the bootfile. Once the target server obtains the bootfile from the TFTP server, it launches the file, which allows the target server to begin the boot process. The bootfile contains information about contacting Provisioning Services." protocol=UDP profile=domain,private,public dir=in localport=69 action=allow

netsh advfirewall firewall add rule name="Citrix (Stream Service)" description="The target server contacts Provisioning Services requesting a vDisk." protocol=UDP profile=domain,private,public dir=in localport=6910-6930 action=allow

netsh advfirewall firewall add rule name="Citrix (License Server)" description="When the target server is online, Provisioning Services contacts the License Server to obtain a connection license." protocol=TCP profile=domain,private,public dir=in localport=27000 action=allow

netsh advfirewall firewall add rule name="Citrix (Console Communication)" description="This port allows the provisioning Server to connect to the PVS Farm." protocol=TCP profile=domain,private,public dir=in localport=54321-54322 action=allow

netsh advfirewall firewall add rule name="Citrix (Provisioning Server Farm Communication)" description="This port allows the operating system to be streamed to the targets." protocol=UDP profile=domain,private,public dir=in localport=6890-6909 action=allow

netsh advfirewall firewall add rule name="Citrix (TSB)" description="This Port is used in the boot-up process" protocol=UDP profile=domain,private,public dir=in localport=6969 action=allow

netsh advfirewall firewall add rule name="Citrix (Write Cache Communication)" description="This is for communincations between the target and the write cache" protocol=UDP profile=domain,private,public dir=in localport=10802-10803 action=allow

Enjoy!

DID YOU KNOW? MSCORSVW.EXE TIP

I just got finished installing the SQL 2005 tools and noticed that there was a process called mscorsvw.exe sucking up resources, around 90% of my CPU. My natural instinct would be to kill the process or reboot my machine which would probably deal with the issue, but I decided to give it a moment or two to see if it settled down. Anyway, eventually it did settle down, but it did remain in memory, so I did a little digging and found out the following information and found the following:

When mscorsvw.exe takes up resources, it is precompiling .NET assemblies in the background. Once it's done, it will go away. Typically, after you install the .NET Redist, it will be done with the high priority assemblies in 5 to 10 minutes and then will wait until your computer is idle to process the low priority assemblies. Once it does that it will shutdown and you won't see mscorsvw.exe. One important thing is that while you may see 100% CPU usage, the compilation happens in a process with low priority, so it tries not to steal the CPU for other stuff you are doing. Once everything is compiled, assemblies will now be able to share pages across different processes and warm start up will be typically much faster, so we're not throwing away your cycles.

This got me thinking that if it is still doing stuff in the background after I “finished” my install, then maybe my install really isn’t finished at all. I dug a little further and found that there is a way to force all of the remaining items to be compiled (or is that pre-compiled?) with a command called NGEN.exe. You can find this command in the C:\Windows\Microsoft.NET\Framework\v2.0.50727 (probably based on .NET version) folder. Go to this folder and from a command prompt issue the following command:

NGEN executequeueditems

then stand back and watch it go! In my case it ran for around seven minutes before it was done. I can now feel comfortable that my install is truly finished!

You can also use this command at anytime to see if there is anything queued up waiting to be executed:

NGEN queue status