Direct Sponsors

Tuesday, February 25, 2014

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"

Using this command will cause the system to enumerate all of the logs and then clear each one.

To really supercharge the above you can always do this, to nuke all logs on all of your servers in your farm!For /f “skip=3” %s in (‘QFarm /Online’) Do For /F "tokens=*" %E in (‘wevutil el /r:%s’) do wevutil cl "%E" /r:%s

Careful! The above command will query *all* online servers and clear out all logs on all servers, no prompts and must be run on a Citrix Server in the desired farm (for QFARM to function)!

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

Monday, February 3, 2014

I recently had to make a provisioned XenApp 6.5 vDisk boot on Cisco UCS B-Series blades outfitted with a Cisco VIC network interface card (probably the most common UCS configuration). Not much information out there (actually none) about PVS & UCS, so I thought I’d share the couple of roadblocks I hit and their solutions: (to be clear, I’m referring here to streaming vDisks directly to UCS hardware, not to some wussyVM-on-hypervisor-on-UCSembarrassment! [Politically Correct edit by ME:)] ;))

(1) The first issue was that my first blade refused to PXE boot with Provisioning Services -- after making contact with PVS and displaying the “vDisk found” message, it just sat there like a lox and went no further. That turned out to be a firmware version issue requiring downgrading to a previous firmware release (which actually is the sort of thing that’s easy to do with UCS since the desired firmware package for a particular blade is specified as part of the blade’s “profile” in the UCS management console). The initial (non-working) firmware release was 2.1(2a) and the release that resolved the PXE issue was the earlier 2.1(1b) which we happened to already have available in the UCS console. My (unconfirmed) suspicion is that we could successfully have gone as high as 2.1(1f), the release immediately before 2.1(2a), because the latter’s release notes trumpet the implementation of “VIC PXE boot optimization”, which is probably what broke PXE as far as PVS is concerned.

(2) Once the vDisk was successfully booting on that first UCS blade, the next issue was that it refused to boot on an identically configured second blade. It would get through PXE, then through the scrolling Windows boot screen, but at the point at which the screen would normally go gray and the mouse pointer appear (indicating the switch to Windows drivers), it would instead blue screen with stop code 0x7B (INACCESSIBLE BOOT DEVICE). That would normally suggest that the new blade’s NIC was somehow different than the original blade’s -- things like even minor PnP ID differences, such as a different revision code, or a different bus slot, would cause the NIC to be seen as different from the original and, since the new one doesn’t yet have a corresponding network connection (with its myriad bindings) registered in the image, the PVS target software has nothing to “latch on to” to continue the boot process. Yet when I reviewed the two blades’ VICs in Device Manager (after booting the second blade from a local disk), I could see no difference in PnP ID, bus ID, slot ID or function ID, i.e. they were in fact identical.

But the Registry told a different story: although the PnP ID key for the two VICs was identical (i.e. the corresponding subkey name under HKLM\SYSTEM\CurrentControlSet\Enum\PCI was the same for both), the “instance ID” (the subkey of the PnP ID key) was different! -- With most hardware, that’s not supposed to happen: identical devices plugged into the same bus slot on identical hardware should generate the same instance ID, based as it usually is on some private “recipe” that involves the bus ID, slot ID and function ID. Upon closer examination, those instance IDs were in this case made up of each VIC’s hex MAC address, along with some additional pad digits. The prospects for booting a single vDisk on multiple UCS blades were at that point looking bleak, especially after a call to Cisco (during which a detailed education on PnP and instance IDs had to be administered :)) led to the conclusion that nothing is available for configuration in a UCS profile or BIOS to yield consistent (non-unique) device instance IDs.

Thankfully, Microsoft had previously encountered a similar issue (see Microsoft KB 2550978, “0x0000007B Stop error after you replace an identical iSCSI network adapter…” and Citrix KB CTX125317, “Unable to Stream to Non-Master Target Dell Physical Hosts”) and this had resulted in hotfix KB2550978 (for Windows 2008 R2 SP1) which fundamentally changes the way Windows looks at hardware devices, basically changing from the rigid “if PnP ID and instance ID don’t match what I already have, then it’s a new device” to the looser “if PnP ID and bus/slot/function IDs match something I have, I’m willing to assume it’s the same device”. The further good news is that, despite Citrix stating the contrary, this hotfix can in fact be installed successfully on a streamed vDisk (i.e. after the PVS Target software), so no tedious reverse image was required to apply the hotfix and make the vDisk bootable on multiple UCS blades. By the way, that hotfix goes to the top of my “must have” list for all new builds (may not always be immediately necessary, but sure can’t hurt!)

(3) Lastly, a minor (possibly irresolvable) issue: Cisco UCS B-Series blades with Cisco VICs don’t appear to support Wake-On-LAN, so they can’t be powered on from the PVS console. If the case currently open with Cisco uncovers a solution to that, I’ll be sure to share it.