Microsoft SCVMM, Citrix PVS and Powershell: Some quick tips

Microsoft SCVMMAnother week, another reference architecture in the making… This time I’m working on a new reference architecture for Hyper-V 2016, SCVMM 2016 and XenDesktop 7.13. Obviously PVS 7.13 is in the mix too so I’ve been building out the environment but needed some PowerShell one-liners and easy scripts to get some work done and figured I could put them in a short blog for my own reference.

Using the usual setup within our labs required installing the SCVMM console on our DDC(s) so that’s where I started. Luckily the console installation comes with the PoSH cmdlets by itself, the console even loads the cmdlets via this shortcut: 

SCVMM

Original source: http://vniklas.djungeln.se

 

Setting up PVS PowerShell is a little bit more complicated as it requires a DLL to be registered:

Registration of McliPSSnapIn.dll using Import-Module If the snap-in later needs to be registered in PowerShell, this can be manually done by running one of the following command in PowerShell. The path where the Citrix.PVS.SnapIn.dll is installed needs to be used.

A very useful document when working with the PVS PowerShell cmdlets is the Citrix Provisioning Services 7.13 PowerShell with Objects Programmer’s Guide.

 

My typical PVS workflow looks as following: 

Screen Shot 2017-06-13 at 12.45.38

After all the installations, I wanted to start deploying a Windows 10 based machine catalog using Citrix PVS. Because I used the base image for my MCS-based testing too I knew the image was ok and could be used in the PVS scenario too.

I forgot to set the VM network interface to Legacy NIC so PXE boot didn’t work the first time, after changing the synthetic network interface to a legacy network interface the PXE boot did its job and I was able to create a VHDX on my PVS server to be used as vDisk. 

Running the XenDesktop Streaming Wizard from the PVS console gave me an unexpected result, it said it failed on 40 devices while other went without issues. Looking in SCVMM I only had a few desktops including ones with duplicate names.

After fixing that and getting ready for the testing I was wondering if I could do the same with PVS/SCVMM PowerShell one-liners which worked out ok although SCVMM network is different than what I’m used to which resulted in a bunch of VMs configured with no VM network and the identical mac addresses.

Here are a couple of my one-liners that helped during testing:

Starting all VMs that don’t start with “NTNX” as our CVM (Controller VMs) names typically start with “NTNX-“:

Stopping all VMs with a certain name that are running:

Check which VMs are configured for which network (again excluding the CVMs):

Check which VMs don’t have a VM network configured:

Count the number of VMs that don’t have a VM network configured:

Change the VM network configuration for a VM (excluding the CVMs):

Listing VMs with a certain MAC address as I scripted VM creation but didn’t set the mac address being unique (lesson learned here!):

Changing the mac addresses of VMs with a duplicate Mac address:

Getting the mac addresses from VMs and placing them in an existing PVS device collection:

Moving a specific range of VMs to a specific host:

 

 

 

The following two tabs change content below.

Kees Baggerman

Kees Baggerman is a Staff Solutions Architect for End User Computing at Nutanix. Kees has driven numerous Microsoft and Citrix, and RES infrastructures functional/technical designs, migrations, implementations engagements over the years.

2 comments

  1. andymwood says:

    “Running the XenDesktop Streaming Wizard from the PVS console gave me an unexpected result, it said it failed on 40 devices while other went without issues. Looking in SCVMM I only had a few desktops including ones with duplicate names…After fixing that and getting ready for the testing”

    Can you give insight into what you fixed? Had a couple of people say that PVS+HyperV can be troublesome – sort of feels like the PVS Support team / testing isn’t as rigorous as it could be.

    • k.baggerman says:

      In this case I think it was 3 seperate things:

      1) Windows Update on the PVS Server
      2) Windows Update on the SCVMM Server side
      3) Disabling a scheduled job that jacked up the VM networking piece

Leave a Reply