CITRIX VOYAGE: March 2017

Difference between MCS and PVS

Configuring PVS for High Availability with UEFI Booting and PXE service

Instructions

Configuring PVS for High availability with UEFI booting and PXE service

Requirements and configuration:

PVS 7.8 installed on all servers
PXE service configured to run on multiple PVS servers
Option 11 configured on the DHCP server for multiple PVS servers.
Vdisk stores configured with multiple PVS servers:

Additional information:

We can split a PVS target booting into 4 tasks.

Task 1

PXE client on target device getting an IP address and scope options.

IP address will come from DHCP server.

Scope options there are two options:

Scope options for PXE are defined on dhcp server

options 66 and 67 specify the server name and file name for tftp retrieval of the pxe bootstrap file

PXE server (option 60, doesn’t need to be configured)

PXE server responds to DHCP request with PXE information, giving its own server name, and the appropriate file name for tftp retrieval of the pxe bootstrap file

Task 2

PXE client retrieves boot file via TFTP

Option 66&67:

PXE client retrieves boot file as specified in scope options, this can be load balanced and configured for HA with Netscaler

Round robin can be used for also load balancing, but not for HA, as there is no recovery if one tftp server is offline

PXE server:

The PXE server which responded first is used by PXE client.

PXE server specifies itself as the source tftp server, and provides the appropriate file name

In PVS 7.8, PXE service can provide gen1/bios boot file- ardbp32.bin, or gen2/uefi file – pvsnbpx64.efi, depending on the pxe client request

Task 3

PXE client executes boot file which handles further booting, and the boot file contacts PVS login server.

Gen1/bios:

Ardbp32.bin has been preconfigured with the addresses of PVS login servers

Gen2/uefi:

pvsnbpx64.efi is a signed file and cannot be preconfigured with PVS login servers.
Instead it will retrieve the location of PVS login servers from DHCP scope options, using either option 11, or option 17.
Option 17 can be used to specify a single PVS login server in the format: pvs:[192.168.0.1]:17:6910

There is no HA for login servers in this scenario

Option 11 can be used to specify multiple PVS login servers.

As multiple login servers are specified, and non-responsive servers are skipped, this is HA appropriate.

Task 4

PVS login server finds vdisk assigned to target device and tells the target device to switch to PVS streaming server

Provide multiple PVS servers are configured to stream a vdisk, this will be highly available
If a PVS server is offline, a target device will not be instructed to stream from it

HOW TO UPDATE V DISK

Updater Device

Create a new Updater Target Device that is only used when you need to update a vDisk. You can create the Updater device manually or you can use the XenDesktop Setup Wizard.
Put the Updater device in a new Device Collection. This is to avoid assigning the device to a Catalog in Studio. Users must not connect to an Updater device while it is powered on.
Set the Updater device to boot from the Maintenance Type. This is used by the Versioning method of updating a vDisk.
When adding the Updater device to Active Directory, be mindful of group policies. Sometimes it is helpful to apply the group policies to the Updater device so they are stored in the vDisk you are updating.
An Updater device can only boot from one vDisk at a time but it can boot from any vDisk. If you need to do updates to multiple vDisks simultaneously, create more Updater devices.
If you are using Enterprise Software Deployment tools (e.g. System Center Configuration Manager) to maintain a vDisk, keep the Updater device constantly booted to a Maintenance version so the ESD tool can push updates to it. This basically requires a separate Updater device for each vDisk.

Update a vDisk – Versioning Method

In the Provisioning Services Console, right-click a Standard Mode vDisk, and click Versions.
In the vDisk Versions window, click New.

Notice that the Access is set to Maintenance. Click Done.

If you look at the physical location where the vDisks are stored, you’ll see a new .avhdx file.
Go to the properties of an Updater Target Device, and change the Type to Maintenance. You’ll use this Target Device to update the vDisk. Make sure this Target Device you are using for vDisk Updating is not in any Delivery Group so that users don’t accidentally connect to it when it is powered on.

Of course this Target Device will need to be configured to use the vDisk you are updating.
Power on the Updater Target Device.
If you did not configure the DWORD registry value HKLM\Software\Citrix\ProvisioningServices\StreamProcess\SkipBootMenu to 1 on the Provisioning Servers, then you’ll see a boot menu.
Login to your Updater Target Device. The Virtual Disk Status icon by the clock should indicate that the vDisk Mode is now Read/Write.
Make any desired changes.
The PvS Image Optimization tool disables Windows Update. To install Windows Updates, use the following script to enable Windows Update, install updates, then disable Windows Update – http://www.xenappblog.com/2013/prepare-a-provisioning-services-vdisk-for-standard-mode/
Before powering off the target device, run your sealing tasks. Run antivirus sealing tasks.
- For Sophos, refer to http://www.sophos.com/en-us/support/knowledgebase/12561.aspx.
- Symantec: Run a full scan and then run the Virtual Image Exception tool – http://www.symantec.com/business/support/index?page=content&id=TECH173650
- Symantec: see the Provisioning Services script at http://www.symantec.com/business/support/index?page=content&id=TECH123419
- Trend Micro: See VDA > Antivirus for links to Trend Micro documents.
Citrix Blog Post Sealing Steps After Updating a vDisk contains a list of commands to seal an image for Provisioning Services.
Login Base Image Script Framework (BIS-F) automates many sealing tasks. The script is configurable using Group Policy. 💡
Power off the target device so the vDisk is no longer being used.
Go back to the Versions window for the vDisk.
Highlight the version you just updated, and click Promote.
Best practice is to promote it to Test first. Or you can go directly to Production if you’re confident that your updates won’t cause any problems. Note: if you select Immediate, it won’t take effect until the Target Devices are rebooted. For scheduled promotion, the Target Devices must be rebooted after the scheduled date and time.
The Replication icon should have a warning icon on it indicating that you need to copy the files to the other Provisioning Services server.
Only copy the .avhdx and .pvp files. Do not copy the .lok file.

Another method of copying the vDisk files is by using Robocopy:

Robocopy D:\vDisks \\pvs02\d$\vDisks *.vhd *.avhd *.pvp /b /mir /xf *.lok /xd WriteCache /xo

Citrix Blog Post vDisk Replicator Utility has a GUI utility script that can replicate vDisks between PvS Sites and between PvS Farms. 💡
Then click the Refresh button, and the warning icon should go away.

Boot a Target Device that is set to boot the Test vDisk Type.
Once testing is complete, promote the vDisk version again.
Immediate means it will take effect only after Target Devices are rebooted, whether immediately or later. Scheduled means the Target Device has to be rebooted after the scheduled date and time before it takes effect; if the Target Device has been rebooted before the scheduled date, then the older version is still in effect. Click OK.
If you need to Revert, you can use the Revert button, or the drop-down on top of the window.

Merge Versions

Citrix recommends no more than five .avhd files in the snapshot chain. To collapse the chain of .avhd files, you can Merge the versions. Don’t Merge until the files on both Provisioning Servers are replicated.
You can merge (Merged Updates) multiple .avhdx files into a single new .avhdx file that is linked to the original base file. Or you can merge (Merged Base) the original base, plus all of the .avhdx files into a new base .vhdx file, without any linked .avhdx files.
The Merged Base process creates a whole new .vhdx file that is the same size or larger than the original base. After merging, replicate the merged file to both Provisioning Servers.
Make sure there is no warning icon on the Replication button.
If your merged version is currently in Test mode, then you can promote it to Production.
After merging, you can delete older versions if you don’t need to revert to them.

Citrix CTX207112 Managing Provisioning Services VDisk Versions with VhdUtil Tool: CLI tool that can do the following outside of PvS Console:

dump header/footer
merge chain
rename chain

Expand vDisk VHD

To expand a vDisk file, create a Merged Base. Then use normal VHD expansion tools/methods.

One method is described by Trevor Svienson at How do I expand pvs vdisk with versions? at Citrix Discussions. Steps are: (Commands in fixed width font)

Open cmd or powershell as administrator
diskpart
select vdisk file=“<path to your visk>” (e.g. V:\store\my.vhd)
list vdisk (you should now see your vdisk and the path)
expand vdisk maximum=60000 (This is the size in megabytes of the size you want to extend, so 60000 is 60Gb)
attach vdisk
list disk
list volume (take note of the Volume number of the your vdisk, you should see the old size)
select volume 5 (or whatever volume number from list volume command)
extend
list volume (you should now see the size you want for your disk. This should also be seen in the pvs console)
detach vdisk
exit

Reverse Image – BCDEDIT Method

If you want to upgrade the Provisioning Services Target Device Software on a vDisk, and if your current Target Devices Software installation is 7.6 Update 1 or newer then you can simply install the new Target Device Software. No special steps required. However, if your Target Device software is 7.6 or older then you’ll need to Reverse Image as detailed in this section.

If you want to update the NIC driver (e.g. VMware Tools) then you can’t use the normal vDisk versioning process since NIC interruptions will break the connection between Target Device and vDisk. Instead you must reverse image, which essentially disconnects the vDisk from Provisioning Services.

Alternatively, see Aaron Silber How to update VMware Tools without Reverse Imaging – The gist is to add an E1000 NIC, boot from that, upgrade VMware Tools, and then remove the E1000 NIC. 💡

The traditional method of reverse imaging is to use XenConvert (P2PVS.exe), or similar, to copy a vDisk to a local disk, boot from the local disk, make changes, and then run the Imaging Wizard again to copy the local disk back to a new vDisk.

A faster process is to skip XenConvert, and instead boot directly from the vDisk VHD. Windows 7/2008 R2 and newer can boot directly from VHD files. Windows 8/2012 and newer can boot from VHDX files. All you need to do is copy the vDisk VHD/VHDX to a Windows machine’s local C: drive, run bcdedit to configure booting to the VHD/VHDX, reboot into the VHD/VHDX, make your changes, reboot back into the original Windows OS, copy the VHD/VHDX back to PvS and import it. Details below:

Note: For Windows 7 vDisks, Enterprise Edition is required in the bootable VHD.

Alternative methods of performing Reverse Image:

George Spiers PVS Reverse Image with VMware vCenter Converter. This article has troubleshooting steps if the reverse image won’t boot.
Jan Hendriks Citrix PVS Reverse Imaging with Windows Backup.

To boot from vDisk VHD (Microsoft TechNet To add a native-boot VHD to an existing Windows 7 boot menu):

In Provisioning Services Console, if using versioning, create a merged base.
Copy the merged based vDisk (VHD file) to any Windows 7, Windows 2008 R2, or newer virtual machine. If VHDX, you’ll need Windows 8, Windows 2012, or newer. Note: the C: drive of the virtual machine must be large enough to contain a fully expanded VHDX file.
Run the following command to export the current BCD configuration:
```
bcdedit /export c:\bcdbackup
```
Run the following command to copy the default BCD entry to a new entry. This outputs a GUID that you will need later.
```
bcdedit /copy {default} /d "vhd boot (locate)"
```
Run the following commands to set the new BCD entry to boot from the VHD file. Replace {guid} with the GUID outputted from the previous command. Include the braces.
```
bcdedit /set {guid} device vhd=[locate]\MyvDisk.vhd
bcdedit /set {guid} osdevice vhd=[locate]\MyvDisk.vhd
```
Make sure you are connected to the console of the virtual machine.
Restart the virtual machine.
When the boot menu appears, select the VHD option. Note: if you see a blue screen, then you might have to enlarge your C: drive so the VHD file can be unpacked.
Login to the virtual machine.
Perform updates:
1. Uninstall the Provisioning Services Target Device software.
2. Upgrade VMware Tools.
3. Reinstall Provisioning Services Target Device software. The Target Device software must be installed after VMware Tools is updated.
When you are done making changes, reboot back into the regular operating system.
Rename the updated VHD file to make it unique.
Copy the updated VHD file to your Provisioning Services Store.
Copy an existing .pvp file and paste it with the same name as your newly updated VHD.
In the Provisioning Services Console, right-click the store, and click Add or Import Existing vDisk.
Click Search.
It should find the new vDisk. Click Add. Click OK.
You can now assign the newly updated vDisk to your Target Devices.

Automatic Scheduled vDisk Update – SCCM

You can use the vDisk Update Management node (and Hosts node) in Provisioning Services Console to schedule an updater machine to power on, receive updates from System Center Configuration Manager, and power off. The new vDisk version can then be automatically promoted to Production, or you can leave it in Maintenance or Test mode and promote it manually.

See the following Citrix links for instructions:

CITRIX VOYAGE

Featured post

Automation | Powershell scripts

Friday, 17 March 2017

Citrix Provisioning Services (PVS)