Creating SCCM device collections based AD OU membership (the easy way)

SCCM is not a product for the faint of heart. Immensely powerful, with more features and options than the average casual user can learn.

During recent VDI testing I was working with enough desktops to warrant splitting them up within SCCM “patch install” test. I planned to split my desktops between two SCCM device collections.

You cannot simply drag and drop desktops into a SCCM device collection. You must populate it based on some item of your choosing. I decided to use OU membership as my desktops were already split between two OU’s within AD.

It turns out there is a trick to populating the path to the OU you wish to filter on in the device collection. The following steps show the process of creating the SCCM device collection, including the trick. The following instructions are based on Microsoft SCCM 2012 SP1.

Select the option to Create Device Collection in the SCCM console.


Provide a Name and Limiting Collection for the device collection. I selected All Systems as my limiting collection so that all systems detected by SCCM are eligible to be members of the collection. Click Next when ready.


Time to define the membership rule that will populate the collection. Click Add Rule – Query Rule.



Enter a Name for the rule, and click Edit Query Statement.



Click the Criteria tab, and then the properties icon (looks like a gold star; only icon available to select).



Click Select.



In the Attribute Class drop down menu, select System Resource. In the Attribute drop down menu, select System OU Name. Click Ok.


There is where we make things easy for ourselves and force SCCM to fill in the path to the OU for us. In the Operator drop down menu, select is equal to. Click the Value button.



SCCM will then present us with a list of OU’s available for selection. Since I limited SCCM to a specific parent OU’s, only some of my AD OUs are listed. Select the OU you wish to be the basis of the device collection, and click Ok. Click Ok again to close the parent Criterion Properties window and return to the Query Statement Properties window.


The Query Statement Properties window will know display your custom query. Click Ok to return to the Query Rule Properties window, and Ok again to return to the Create Device Collection Wizard window.


The membership rule we created is now displayed in the wizard. In my example I have also checked Use incremental updates for this collection which enables SCCM to update the collection membership more frequently than just the default weekly full update. Click Next.


Review the summary window to ensure that the desired settings have been selected and click Next to create the device collection.


Review the completion window to confirm that the device collection was created successfully.


In the SCCM console, review the Device Collections page and confirm that your collection was created. If there were AD computer accounts within the target OU, they should show up in the Member Count column as shown. My lab environment is currently deploying desktops, so only a small number of accounts are shown in SCCM. Since I enabled incremental updates, the group will automatically grow as additional AD accounts are created.



Now that the device collection has been created, I am able to select it when performing various SCCM tasks. While it would be nice to be able to simply drag and drop, that isn’t the optimal way to use SCCM as it makes it more likely that you will overlook adding new AD computer accounts to the appropriate device collection.

How and why to replace the default VMware View Composer SSL certificate – Part 2

In Part 1 we went through all the steps needed to generate a new SSL certificate for View Composer. We were left with a file titled rui.pfx, which we need to import into our View Composer certificate store.

Step 1 – Import the certificate to the local certificate store

Open a MMC console, then from the File menu add the Certificates snap-in (Add/Remove Snap-in from the menu).


We need to manage the Computer account….:


For the Local computer:


Click Ok once you have added the snap-in.

Expand Personal – Certificates. You’ll see the default Composer SSL certificate there.


Right click on the Certificates folder and select All Tasks – Import.


Go through the wizard, selecting the rui.pfx file we previously copied to the server. You’ll need to change the file extension to Personal Information Exchange to see the file.


Click Next to move through the wizard.

The next decision is yours. If you mark the certificates as exportable you do open up a potential security risk as someone could come along and grab a full copy of the certificate. You already have a copy of the PFX file (which you will protect right?), so lets leave the settings at the default. Fill in the password we selected when generating the PFX file (testpassword) and click Next.


The destination store should already be what we want since we selected in in the beginning. If not, select Personal as shown and click Next then Finish. You will get a dialog box indicating that the action was successful.


Step 2 – Activate the certificate

From the View Management Console dashboard; note that our current View Composer certificate is untrusted but accepted (I accepted it during the initial configuration, prior to replacing the certificate):


Stop the VMware View Composer service.

From the command line, change into the View Composer install directory. It should be Program Files (x86)VMwareVMware View Composer.

Execute the command:

SviConfig.exe –operation=replacecertificate -delete=false

The delete=false leaves the default SSL certificate in place, so you can switch to it if you want.

Select the certificate you wish to activate. It should be obvious since if has the details you entered when generating the certificate request. We want certificate 1; press Enter to bind the certificate.


You should get confirmation:


Start the View Composer Service. Check the Composer Server event logs for any issues, but assuming that you followed the directions as indicated (known valid for View 5.1) Composer should be working as expected.

Go back to the View dashboard, hit refresh, and click on the View Composer Server again. The SSL Certificate should now show as valid.


You now have a trusted certificate on your View Composer Server, and a usable backup of the Composer Server SSL certificate (with private key).

How and why to replace the default VMware View Composer SSL certificate–Part 1

Lets pretend for a moment that you do not back up full virtual machines, and prefer a more minimal approach to disaster recovery. VMware View Composer is a good candidate for this, as all you really need to restore it is the Composer database (which is likely hosted elsewhere), and the RSA keystore data OR a SSL certificate that can be exported with the private key. The default View Composer (self signed) SSL certificate cannot be exported, so you must export the RSA keystore using the process outlined here if you wish to be able to restore Composer on a new server and continue to use the existing Composer database.

You restore the RSA keystore on the new host server prior to re-installing View Composer. Composer will install a new self-signed certificate, but since the keystore data is there the existing Composer database can still be used. While that works fine, I’m more interested in using certificate that was signed by an internal CA, as it will be trusted by the View Connection Server AND I have full control over the certificate.

Problem number 1 is that you cannot export the default Composer SSL certificate. Unlike the vCenter certificates, the View Composer certificate is stored within the Windows certificate store and is not marked as exportable. This is a good of reason as any to replace this certificate immediately after installing View Composer, or ideally before it is even installed as you can then select it during the installation process.

Note: The procedure is the same regardless of whether or not you are using a dedicated View Composer Server OR if you installed View Composer directly on your vCenter Server.

Here sits the default View Composer SSL certificate, valid for 2 years:


The tools we need to perform this task include:

  • A trusted certificate authority. I’ll be using a Microsoft Root CA since that is automatically trusted by the members of my lab domain.
  • An installed and configured copy of OpenSSL for Windows, which you can get from:
    • Note: Don’t forgot to install the Visual C++ 2008 Redistributables first.
    • Note 2: Have a Linux box? OpenSSL was ported from Linux so you can do all of this from Linux if you want.
    • Note 3: Yes you could do this directly through the Microsoft CA tool, but to do that you need a custom certificate request template that allows you to export the certificate keys (which is something I wanted to do). Learning to use OpenSSL is helpful as you can use it to generate the PFX file used to replace your vCenter and View Connection Server SSL certificates (something I will do posts on later).
How to create the certificate request

Edit the default openssl.cfg file. Assuming you performed a default installation, this file is located in C:OpenSSL-Win32bin.

Scroll down to the the [ req ]section and remove the # to uncomment out this line (if the line isn’t present, just add it at the end of the section):

req_extensions = v3_req

Scroll down to the [ v3_req ] section and add a new subjectAltNameline listing the required DNS names of the View Composer server including the full FQDN:

subjectAltName = "DNS:viewcomp-01.vjason.local,DNS:viewcomp-01"

OpenSSL was ported from Linux and still expects the config file to be in a specific Linux path. Due to this, you need to add an environment variable pointing to the openssl.cfg file. From the Windows command prompt enter the command:

set OPENSSL_CONF=C:OpenSSL-Win32binopenssl.cfg

Enter the following command to generate your SSL key:

openssl.exe genrsa 2048 > rui.key

Assuming that you configured everything as expected, you should see output similar to this:

Loading 'screen' into random state - done
Generating RSA private key, 2048 bit long modulus
e is 65537 (0x10001)

Enter the following command to generate your certificate request:

openssl req -new -nodes -out rui.csr -keyout rui.key

You should see output similar to this:

Loading 'screen' into random state - done
Generating a 1024 bit RSA private key
writing new private key to 'rui.key'

Followed by the familiar cert request questions. All I am really interested in is the question in bold; make sure you enter in the FQDN for your Composer server:

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:NC
Locality Name (eg, city) []:Research Triangle Park
Organization Name (eg, company) [Internet Widgits Pty Ltd]
Organizational Unit Name (eg, section) []:Lab
Common Name (e.g. server FQDN or YOUR name) []:viewcomp-01.vjason.local
Email Address []
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:Password123
An optional company name []:

Once complete, you will have certificate request file named rui.csr.

Generating the new certificate

Open the Microsoft CA web interface and select Request a certificate


Then select advanced certificate request.


We will be pasting in the contents of the rui.csr file, so we need to select Submit a certificate request….. (I cut off the link; this is one of two options):


Paste the full contents of rui.csr in the Saved Request window and change the Certificate Template to Web Server. Click Submit when complete.


Answer Yes here to complete the request.


We need to export the certificate with the private key rather than download it, so you can close the Certificate Services web interface at this point.

Approve the certificate request (if required) in your Microsoft Root CA MMC console. I don’t have a screenshot of a pending request, but you would see it here:


Once approved, we need to export the certificate. Open the Issued Certificates folder and double click on the certificate you wish to export. In my lab it was the last certificate issued:


Click on the Details tab of the Certificate window and press the Copy to File button.


Click Next in the first window in the Certificate Export Wizard, then select the Base-64 encoded X.509 (.CER) radio button, and finally click Next.


Save the file as rui.cer and copy it into the C:OpenSSL-Win32bin directory on the server with OpenSSL installed. Rename the file rui.crt, then run the following command (Note: I used testpassword as that VMware uses with vCenter PFX files. For View you can use anything but remember it since you’ll need it later):

openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui
-passout pass:testpassword -out rui.pfx

You should see output similar to this when done:

Loading ‘screen’ into random state – done

Copy the rui.pfx file to the server that is hosting View Composer. You could install it remotely, but there are parts of this procedure that require local server access so it is just easier to copy it directly to the server.

Note: That rui.pfx file is what you want to back up. If the event you need to rebuild your View Composer Server, you will want to install that certificate first (see the second half of this post for how) and select it during the installation of View Composer.

This concludes the first half of this post. The second half will be much shorter and very simple by comparison, I promise.

Tuning Windows 8 for EUC deployments

I must preface this post by saying that my goal was to “tune” Windows 8 to achieve IOPS and CPU numbers that were equal to if not better than that of Windows 7. If the Internet is to be believed, this should not have been difficult. The truth is that in the EUC world things are not as simple as they are in the physical desktop world.

One of the easiest ways to reduce CPU utilization in Windows 7 was to disable Aero. I have nothing against Aero, but when you are trying to squeeze as many desktops as you can on each server CPU core it is a luxury you can do without. With Windows 8, Aero is now mandatory (at least it appears that way). No more disabling Aero to squeeze every last bit of performance out of your image.

Aero notwithstanding, tuning Windows 8 is similar in many ways to tuning Windows 7. My tuning is geared towards task worker environments where the focus is on applications.

The following services, unless required, should be disabled (see the VMware View Optimization Guide for Windows 7 for an explanation of each service):

BitLocker Drive Encryption Service
Block Level Backup Engine Service
Diagnostic Policy Service
Home Group Listener
Home Group Provider
IP Helper
Microsoft iSCSI Initiator Service
Network Connectivity Assistant
Secure Socket Tunnrling Protocol Service
Security Center
UPnP Host Service
Windows Backup
Windows Defender
Windows Error Reporting Service
Windows Firewall
Windows Media Player Network Sharing Service
Windows Update
WLAN AutoConfig
WWAN AutoConfig
SSDP Discovery

Place the following commands in a batch file and execute it to remove unneeded scheduled tasks. Details about each task can be reviewed in the Windows Task Schedule prior to deletion if you are curious about what each does.

SCHTASKS /Delete /TN “MicrosoftWindowsApplication ExperienceAitAgent” /F
SCHTASKS /Delete /TN “MicrosoftWindowsApplication ExperienceProgramDataUpdater” /F
SCHTASKS /Delete /TN “MicrosoftWindowsApplication ExperienceStartupAppTask” /F
SCHTASKS /Delete /TN “MicrosoftWindowsAutochkProxy” /F
SCHTASKS /Delete /TN “MicrosoftWindowsBluetoothUninstallDeviceTask” /F
SCHTASKS /Delete /TN “MicrosoftWindowsCustomer Experience Improvement ProgramBthSQM” /F
SCHTASKS /Delete /TN “MicrosoftWindowsCustomer Experience Improvement ProgramConsolidator” /F
SCHTASKS /Delete /TN “MicrosoftWindowsCustomer Experience Improvement ProgramKernelCeipTask” /F
SCHTASKS /Delete /TN “MicrosoftWindowsCustomer Experience Improvement ProgramUsbCeip” /F
SCHTASKS /Delete /TN “MicrosoftWindowsDefragScheduledDefrag” /F
SCHTASKS /Delete /TN “MicrosoftWindowsDiskDiagnosticMicrosoft-Windows-DiskDiagnosticDataCollector” /F
SCHTASKS /Delete /TN “MicrosoftWindowsDiskDiagnosticMicrosoft-Windows-DiskDiagnosticResolver” /F
SCHTASKS /Delete /TN “MicrosoftWindowsFileHistoryFile History (maintenance mode)” /F
SCHTASKS /Delete /TN “MicrosoftWindowsLiveRoamingMaintenanceTask” /F
SCHTASKS /Delete /TN “MicrosoftWindowsLiveRoamingSynchronizeWithStorage” /F
SCHTASKS /Delete /TN “MicrosoftWindowsMaintenanceWinSAT” /F
SCHTASKS /Delete /TN “MicrosoftWindowsMobile Broadband AccountsMNO Metadata Parser” /F
SCHTASKS /Delete /TN “MicrosoftWindowsMobilePCHotStart” /F
SCHTASKS /Delete /TN “MicrosoftWindowsPower Efficiency DiagnosticsAnalyzeSystem” /F
SCHTASKS /Delete /TN “MicrosoftWindowsRasMobilityManager” /F
SCHTASKS /Delete /TN “MicrosoftWindowsSideShowAutoWake” /F
SCHTASKS /Delete /TN “MicrosoftWindowsSideShowGadgetManager” /F
SCHTASKS /Delete /TN “MicrosoftWindowsSideShowSessionAgent” /F
SCHTASKS /Delete /TN “MicrosoftWindowsSideShowSystemDataProviders” /F
SCHTASKS /Delete /TN “MicrosoftWindowsSpacePortSpaceAgentTask” /F
SCHTASKS /Delete /TN “MicrosoftWindowsSystemRestoreSR” /F
SCHTASKS /Delete /TN “MicrosoftWindowsUPnPUPnPHostConfig” /F
SCHTASKS /Delete /TN “MicrosoftWindowsWindows DefenderWindows Defender Cache Maintenance” /F
SCHTASKS /Delete /TN “MicrosoftWindowsWindows DefenderWindows Defender Cleanup” /F
SCHTASKS /Delete /TN “MicrosoftWindowsWindows DefenderWindows Defender Scheduled Scan” /F
SCHTASKS /Delete /TN “MicrosoftWindowsWindows DefenderWindows Defender Verification” /F
SCHTASKS /Delete /TN “MicrosoftWindowsWindows Error ReportingQueueReporting” /F
SCHTASKS /Delete /TN “MicrosoftWindowsWindows Media SharingUpdateLibrary” /F
SCHTASKS /Delete /TN “MicrosoftWindowsWindowsBackupConfigNotification” /F

Use PowerShell to remove the following Appx (Metro) software packages. Wild cards are used to remove packages that are related and include apps that focus on XBox, Zune, Bing, Windows Camera, and Windows Photos.

get-appxpackage -name Microsoft.Bin* | Remove-AppxPackage
get-appxpackage -name Microsoft.XBo* | Remove-AppxPackage
get-appxpackage -name Microsoft.Rea* | Remove-AppxPackage (optional; Microsoft PDF reader)
get-appxpackage -name Microsoft.Zun* | Remove-AppxPackage
get-appxpackage -name microsoft.microsoftsky* | Remove-AppxPackage
get-appxpackage -name Microsoft.Came* | Remove-AppxPackage
get-appxpackage -name microsoft.windowsphotos | Remove-AppxPackage
get-appxpackage -name microsoft.windowscomm* | Remove-AppxPackage

From the Windows Control Panel select “Turn Windows Features On or Off” and disable the following feature:

Windows Gadget Platform

The next settings involve group policies. You can either use traditional group policies applied through Active Directory (AD) or configure the policies on your master image. It is likely that your domain is not yet using Windows Server 2012 domain controllers, so if you want to use AD applied policies you will need to install the Remote Server Administration tools on a Windows 8 desktop (install using “Turn Windows Features On or Off” in the control panel) to edit Windows 8 group policy settings within your domain.

Configure the following Group Policy settings:

Computer Policies – Administrative Templates

System – Internet Communication Management – Internet Communication settings
Turn off access to the store : Enabled
Turn off the Windows Messenger Customer Experience Improvement Program: Enabled
Turn off Windows Customer Experience Improvement Program: Enabled
Turn off Windows Error Reporting: Enabled

System – System Restore
Turn off configuration: Enabled
Turn off System Restore: Enabled

System – Windows File Protection
Set Windows File Protection Scanning: Disabled

System – Windows HotStart
Turn off Windows HotStart: Enabled

Windows Components – Desktop Gadgets
Turn off desktop gadgets: Enabled
Turn off user-installed desktop gadgets: Enabled

Windows Components – Desktop Window Manager
Do not allow Flip3D invocation: Enabled
Do not allow window animations: Enabled
Use solid color for Start background: Enabled

Windows Components – File History
Turn off File History: Enabled

Windows Components – Store
Turn off Automatic Download of updates: Enabled
Turn off the Store application: Enabled

Windows Components – Windows Error Reporting
Disable logging: Enabled
Disable Windows Error Reporting: Enabled

Windows Components – Windows Messenger
Do not automatically start Windows Messenger initially: Enabled

Windows Components – Windows SideShow
Turn off automatic wake: Enabled
Turn off Windows SideShow: Enabled

You have probably noticed that I did not disable any indexing services. When I did this initially I experienced some odd errors within Windows, so for the time being I am leaving it on. With Metro using the search function more and more to find applications and files I think that indexing is likely a critical component of the desktop moving forward.

I will be updating this post over time as I run more tests and learn more about Windows 8. As it is today with these tuning parameters in place I am seeing similar CPU utilization and disk IOPS with Windows 8 as I was in Windows 7. These numbers (9.5 IOPS/desktop and CPU utilization sufficient to run 8 desktops/server CPU core) were observed using LoginVSI “medium” user work load simulations. My master image was Windows Windows 8 x32, 1 vCPU, 1 GB ram, Office 2010, and Adobe Acrobat X, running on VMware vSphere 5.

VMware View 5.1 Storage Accelerator in Action

Early today VMware formally announced the (almost) release of VMware View 5.1. Many assumed that View 5.1 would support vSphere 5 Content Based Read Cache (also known as CBRC); they were correct. For those who have been living under a rock, vSphere 5 has the ability to cache bits of a virtual machine in ram, where latency is measured in nanoseconds and not milliseconds. This is of particular benefit for linked clone virtual machines, where under View 5.x you have up to 1000 clones linked to a single image. Note: CBRC is referred to within VMware View as “VMware View Storage Accelerator”; this is the official term now that View 5.1 has been released.

Andre Leibovici of VMware has had a series of blog posts all about CBRC. Rather than plagiarize all his hard work, I’m going to recommend you visit his site if you want a technical introduction into how CBRC works.

Earlier this week I finished up some testing that shows exactly what CBRC does. The following graphs show IO reduction for three specific scenarios: 2000 desktop boot storm, logon storm, and on demand virus scan storm. View 5.1 allows you to enable caching for either the master replica image OR the master replica image and the persistent disks. My hosts in this case were rather close to overcommitting memory, so I chose to cache the master replica image only to minimize the amount of ram used for the cache. Read this to understand how much ram you will need based on your own settings.

I created these graphs because they are those which show the greatest amount of benefit from CBRC. Remember that much of the EUC storage workload is writes, so I’m looking for read heavy scenarios in order to find out what CBRC can really do.

The stats are all reads of the master replica image measured using ESXTOP. Storage stats are interesting enough, but the truth is if you see less reads at the ESXi host you will see less reads within your storage environment.

The results

So that you have some perspective, you are looking at results for a ESXi host that is running 143 Windows 7 desktops. I was actually testing 2000 desktops at once, but for simplicities sake I am showing the results for only one of my hosts.


Do I really need to explain this? Yes there was still a (small) read spike at the 2 minute mark even with CBRC enabled, but even with that you are looking at over a 95% reduction in reads (red line) to the replica image. Even though vSphere uses at most 2 GB of ram for CBRC, the working set (the data that is actually read) of the master replica image is rather small during boot up.


This is a 90 minute logon storm. Again, the benefits of CBRC during this window are obvious. With CBRC enabled (blue line) the reads to the replica image were again reduced by over 95% on average. This would be of great benefit in environments where logon storms were a frequent occurrence.


Let me preface this graph by saying that you really should be using antivirus solutions that are optimized for EUC environments. This includes vShield Endpoint (with McAfee or Trend Micro plugins) or even McAfee MOVE. I’ve tested them all, and they are a huge improvement over traditional client-based AV tools. Now that I’ve gotten that out of the way, you are looking at an AV scan storm that used the McAfee command line AV client. Each AV session was initiated one right after another, a process which takes about 5-7 seconds per desktop. In this case not only was IO reduced by over 70% (blue line), with CBRC enabled the scans finished in less than a third of the time of the “no CBRC” test. AV scan storms are among the most “stressful” storage tests I do, and CBRC enabled amazing results.

The question is does CBRC change my storage requirements? My opinion: In most cases not really. If I were to show you steady state IO during a Login VSI user simulation test you would see maybe a percent or two reduction in IO to the replica master image, which means that you really can’t adjust your core storage design. I consider CBRC a safety valve that helps you maintain desktop performance during those periods of load that may otherwise affect desktop performance. Given that only a few GB of ram are required, you may find the CBRC a no brainer. As always, test in a lab or with a small pilot first before deploying into production.

– Jason

Antivirus for VDI – McAfee MOVE

Antivirus for virtual desktops is not a fun topic, especially when you are trying to shoehorn as many virtual desktops per CPU core as you can onto a server. Snark from Mac users aside, just about every antivirus platform out there will impact the performance of your workstation in some way, usually cpu, ram, or disk related.

Before I start, yes I know that there are alternatives to McAfee MOVE. McAfee MOVE just happens to be the one I tested since I have access to it and years of experience with ePolicy Orchestrator and VirusScan.

The McAfee MOVE Antivirus solution consists of multiple components, each of which plays a different role in the overall solution:

  • McAfee ePolicy Orchestrator Server (ePO) 4.6 – Enables centralized management of the McAfee software products that comprise the MOVE solution. ePO can be installed on Windows Server 2003 SP2 or newer servers, and McAfee recommends using a dedicated server when managing more than 250 clients.
  • McAfee MOVE Antivirus Offload Server – The MOVE Antivirus Offload Server manages the scanning of files from the virtual desktop environment. McAfee VirusScan 8.8 is installed on the MOVE server and is responsible for performing actual virus scans. The number of MOVE servers required is dependent on the aggregate number of CPU cores present in the hypervisors that host the virtual desktops; the actual sizing requirements will be discussed later in the chapter. McAfee MOVE server requires Windows Server 2008 SP2 or Windows Server 2008R2 SP1.
  • McAfee MOVE Antivirus Agent – The McAfee MOVE Agent is preinstalled on the virtual desktop master image and is responsible for enforcing the antivirus scanning policies as configured within McAfee ePolicy Orchestrator. The agent communicates with the MOVE Antivirus Server to determine if and how a file will be scanned based on the ePO policies. The McAfee MOVE Antivirus Agent supports Windows XP SP3, Windows 7, and Windows Server versions 2003 R2 SP2 and newer.
  • McAfee VirusScan 8.8 – VirusScan 8.8 is an antivirus software package used for traditional host-based virus scanning. It is installed on the McAfee MOVE Antivirus Offload server as well as the other servers that comprise the VMware View test environment.
  • McAfee ePolicy Orchestrator (ePO) Agent – The McAfee ePO agent is used to manage a number of different McAfee products. In the case of this solution, ePO is being used to manage servers and desktops running either the McAfee MOVE Antivirus Agent or McAfee VirusScan 8.8. The ePO agent communicates with the ePO server for management, reporting, and McAfee software deployment tasks. The McAfee ePO agent is preinstalled on the virtual desktop master image.

How MOVE Works

The benefit of the McAfee MOVE solution is that it offloads the scanning of files to a dedicated server, the MOVE Antivirus Offload Server. The MOVE Offload Server maintains a cache of what files have been scanned, eliminating the need to scan the files again regardless of what virtual desktop client makes the request. This differs from traditional host-based antivirus solutions which may maintain a similar cache of scanned files, but only for the benefit of the individual host and not other hosts. I created the below diagram to explain how the different components of the McAfee MOVE solution interact with one another.


McAfee MOVE architecture

The virtual desktop client runs the McAfee MOVE client and the ePO agent. The ePO agent enables remote management of the MOVE client by the ePO server, while the MOVE agent is responsible for identifying files that need to be scanned and requesting the scan from the MOVE Antivirus Offload Server.

The McAfee MOVE Antivirus Offload Server runs the MOVE Server software, VirusScan 8.8, and the ePO agent. The MOVE Antivirus Offload Server is responsible for answering file scanning requests from the MOVE clients, determining if the file has been scanned before, and performing the virus scan operations if required. The ePO agent is used for remote management of the VirusScan 8.8 antivirus platform.

The ePO server runs the ePolicy Orchestrator software, which is the management platform for the components that comprise the McAfee MOVE solution. The policies configured within ePO control the parameters within which MOVE operates, both in terms of the configuration of the product itself and policies that govern how and when files are scanned.

McAfee MOVE Sizing

One concern when deploying McAfee MOVE is the number of MOVE Antivirus Offload Servers that will be required. The number of servers required is dependent on the aggregate number of CPU cores, including hyper-threading, present in the hypervisors that host the virtual desktops. McAfee recommends a specific configuration for each MOVE Antivirus Offload Server:

  • Windows Server 2008 SP2 or Windows Server 2008R2 SP1
  • 4 vCPUs
  • 4 GB of ram

McAfee recommends leveraging Microsoft network load balancing (NLB) services to distribute the scanning workload across the MOVE Antivirus Offload Servers. NLB enables the creation of a single virtual IP that is used in place of the dedicated IP’s associated with the individual MOVE servers. This single IP distributes traffic to multiple McAfee MOVE servers based on the NLB settings and whether or not the server can be reached. The process for configuring Microsoft Windows NLB for Windows Server 2008 (and newer) is described in the Microsoft TechNet article Network Load Balancing Deployment Guide.

The McAfee MOVE Antivirus 2.0 Deployment Guide recommends one MOVE Antivirus Offload Server per every 40 vCPUs in the hypervisor cluster, including those created by the enabling of CPU hyper-threading. If the MOVE Antivirus Offload Servers will be installed on the same hypervisors that host the virtual desktops, ten percent of the vCPUs within the hypervisor cluster must be allocated for their use. This means that the hypervisors that will host the MOVE Antivirus Offload Servers will be able to host fewer virtual desktops than may have been otherwise planned for. A minimum of two MOVE Antivirus Offload Servers is recommended at all times for redundancy, regardless of whether or not the hypervisor cluster requires it based on the sizing calculations. The below table details how the number of MOVE Antivirus Offload Servers required increases as the number of vCPUs in the hypervisor cluster increases. A more detailed explanation of MOVE Offload Server sizing is below:

Hypervisors per cluster

Cores per cluster

vCPU per cluster(hyper-threading)

vCPU required for offload scan servers for a cluster (10% of vCPU)

Number of MOVE  Offload Servers required


























MOVE Offload Server sizing

These figures should be applied on a per-hypervisor cluster basis; if more clusters are created additional McAfee MOVE Antivirus Offload Servers should be deployed and dedicated to the new cluster.

Installing McAfee MOVE

The MOVE Agent and ePO agents are installed on the master desktop image prior to the deployment of the virtual desktops. Both components can be installed after the virtual desktops have been deployed, although the impact this will have on the growth of linked clone persistent disks (if applicable) should be considered.

Once the installation of the MOVE and ePO agents has been completed on the virtual desktop master image, additional steps are required to prepare the image for deployment. The following steps should be performed prior to any redeployment of the virtual desktop master image, or if the McAfee Framework service has been started prior to the shutdown of the virtual desktop in preparation for deployment:

  1. Stop the McAfee Framework service.
  2. Delete value for the registry key AgentGUID located in the location determined by the virtual desktop operating system:
    1. 32-bit Windows operating systems — HKEY_LOCAL_MACHINESOFTWARENetwork AssociatesePolicy OrchestratorAgent (32-bit)
    2. 64-bit Windows operating systems — HKEY_LOCAL_MACHINESOFTWAREWow6432NodeNetwork AssociatesePolicy OrchestratorAgent (64-bit)
  3. Power down the workstation and deploy as necessary.

The next time the agent service is started the virtual desktop will generate a new AgentGUID value which will ensure it is able to be managed by McAfee ePolicy Orchestrator.

VMware DRS Rules – MOVE Offload Servers

McAfee recommends that the VMware Distributed Resource Scheduler (DRS) be disabled for the virtual MOVE Antivirus Offload Server guests as scanning activities would be interrupted if a DRS-initiated vMotion were to occur. To accomplish this but still leave DRS enabled for the virtual desktops, a DRS rule was created for each MOVE Antivirus Offload Server that binds the server to a specific hypervisor. To create the DRS rules you must first create virtual machine and host DRS groups; the image below shows the DRS groups as they appear in the DRS Groups Manager tab after they are created. In order to bind a specific virtual server to a specific hypervisor you must create individual DRS group for each hypervisor and each virtual server. These rules and groups are created on a per-cluster basis.


DRS Groups Manager – DRS Rules

Once the DRS groups have been configured you can then create the DRS rules that will bind the MOVE Antivirus Offload Servers to a specific hypervisor. Figure 91 displays a completed DRS rule that binds VDI-MOVE-01, a MOVE Antivirus Offload Server, to hypervisor vJason1. The option Should run on hosts in group is selected rather than Must run on hosts in group to ensure that VMware High Availability (HA) will power on the MOVE Antivirus Offload Server were a HA event involving the hypervisor hosting the MOVE Antivirus Offload Server to occur. You must create a DRS rule for each MOVE Antivirus Offload Server within the cluster.


DRS Rules

MOVE Antivirus Offload Servers

The MOVE Antivirus Offload Server software and VirusScan 8.8 were deployed on servers running Windows Server 2008R2 SP1. The MOVE Antivirus Offload Servers were added to a Microsoft network load balancing (NLB) cluster, per the recommendations from McAfee. The figure below shows the Network Load Balancing Manager interface for the MOVE Antivirus Offload Server NLB cluster. That cluster contains two member servers, VDI-MOVE-01 and VDI-MOVE-02. The virtual IP for the NLB cluster, in the example provided, is what the MOVE clients will use when contacting the MOVE Antivirus Offload Servers.


NLB Cluster containing McAfee MOVE Offload Servers

McAfee ePolicy Orchestrator Configuration

McAfee ePolicy Orchestrator was used to provide a central point of management and reporting for the virtual desktops within the test environment. The figure below shows the System Tree, which provides a hierarchal view of the clients that are being managed by the ePO server.


ePO System Tree View

ePO clients are placed into different groups within the system tree based on default placement rules, automated placement rules, or manually by the ePO administrator. For the purpose of the testing, ePO was configured to place the virtual desktop computers in the appropriate group based on what organizational unit (OU) they reside in within Active Directory. The figure below shows the Synchronization Settings for the ePO group Pool A.


ePO Group Synchronization Settings

ePO is configured to synchronize the ePO group with the computer accounts found in the organizational unit Pool A, which is located in the parent organizational unit Desktops. The Pool A desktops computer accounts were placed in that organizational unit by VMware View when desktop Pool A was created. The reason why the virtual desktops are placed in different groups is in case an additional hypervisor cluster is added; a new cluster would use different MOVE Antivirus Offload Servers and require a unique MOVE ePO policy. The image below shows the Assigned Policies tab for the group Pool A. What is being shown in this case are the policies that are related to the MOVE Client, that are assigned to the Pool A ePO group.


ePO Assigned Policies for Pool A

ePO policies are what are used to control the configuration of McAfee products that support ePO, which includes the MOVE agent. To configure the MOVE Agent on the virtual desktops the policy entries shown in the next two images were configured.


MOVE Agent Policy – General Settings

The highlighted value displayed on the policy General tab is the IP address of the MOVE Antivirus Offload Server NLB cluster previously shown in Figure 92. The IP address must be used; the MOVE Agent does not support the use of DNS names when identifying what MOVE Antivirus Offload Server to use.

The second part of the policy that needed updated was the Scan Items tab, which is shown below.


MOVE Agent Policy – Scan Items

VMware KB Article 1027713, the VMware technical note Anti-Virus Practices for VMware View, and the McAfee MOVE Antivirus 2.0.0 Deployment Guide contain information about files and processes that should be excluded from antivirus scanning. These recommendations were made because the scanning of these files prevented various aspects of the virtual desktops, including the antivirus software, from working correctly. These recommendations were incorporated into the path and process exclusion settings in the McAfee MOVE agent policy. The list of items excluded from scanning includes:


  • Pcoip_server_win32.exe
  • UserProfileManager.exe
  • Winlogon.exe
  • Wsnm.exe
  • Wsnm_jms.exe
  • Wssm.exe


  • McAfeeCommon Framework
  • Pagefile.sys
  • %systemroot%System32Spool (replace %systemroot% with actual Windows directory)
  • %systemroot%SoftwareDistributionDatastore (replace %systemroot% with actual Windows directory)
  • %allusersprofile%NTUser.pol
  • %systemroot%system32GroupPolicyregistry.pol (replace %systemroot% with actual Windows directory)

Once the policies are configured and associated with the appropriate system tree group, the clients should begin to report into the ePO server as shown below.


ePO – Pool A Systems

The Managed State and Last Communication columns indicate if a client is being managed by ePO and when the last time was that client communicated with the ePO server.

McAfee MOVE – Test Results

The McAfee MOVE solution was tested by deploying desktops both with and without the MOVE Agent installed on the master image. Once the desktops were deployed and the virtual desktops all appeared as “managed” in the ePO console, a popular VDI workload generator was used to simulate a user logon storm and steady state workload. The virtual desktops were logged in sequentially over the course of one hour, and the test workload ran for one full hour after the last desktop was logged in and a steady state user load was achieved. Both tests used identical settings; the only difference was whether or not the MOVE agent was installed on the virtual desktops. Three metrics are displayed: storage processor IOPS, ESXi % Processor Time, and ESXi GAVG.

– Storage Processor IOPS

The graph below provides a comparison of the total number of IOPS of both storage processors observed during the tests. The results both tests are shown.

McAfee MOVE – Storage Processor IOPS Comparison

There was no significant difference between the storage processor IOPS observed during either of the the tests.  There was a small increase in IOPS during the logon storm phase of the test associated with the MOVE Antivirus Offload Server needing to scan a number of files for the first time. By the time that the logon storm had completed the MOVE Antivirus Offload Server had cached the scan results for these files, and scanning was not required again on subsequent desktops. This is evident in the IOPS observed during the steady state phase as the IOPS observed varied by less than two percent.

– ESXi – % Processor Time

The image below displays the average ESXi CPU load that was observed during the tests.


McAfee MOVE – ESXi CPU Load

The CPU load results were similar for both tests. A slightly higher CPU load was observed during the first half of the login storm, which can be attributed to the increased antivirus scanning that was occurring during that time period as the antivirus cache was established. As the MOVE Antivirus Offload Server built a cache of files that had been scanned the amount of scans that were required decreased along with the ESXI server CPU load. The CPU load observed during the steady state phase was similar between both tests.

– ESXi – GAVG (disk response time observed at the hypervisor level)

The next figure displays the average ESXi disk response time, also referred to as the GAVG, observed during the tests. The desktops were deployed as linked clones so the response time for the replica LUN and the linked clone LUN are displayed.


The disk response times observed during the both tests were similar for the replica and linked clone LUNs during both the logon storm and steady state phases of the test.


McAfee MOVE provided file level antivirus protection with very little noticeable impact to the virtual desktop. I expected the performance numbers to stabilize as the MOVE cache warmed up, and based on the metrics provided it is obvious that they did. All in all I was pleased with the performance I saw and I would recommend that anyone interested in antivirus designed for VDI look at MOVE and see if it meets their needs. If you are already using ePO you can have MOVE up and running in less than an afternoon.

The McAfee MOVE agent installed on the virtual desktops required less than 29 MB of space and the related services utilized approximately 22 MB of memory and no processor time at idle. When compared to the disk, memory, and CPU utilization of the traditional McAfee VirusScan client as observed during my tests, the McAfee MOVE agent used 75 percent less disk space and 60 percent less memory. This does not include the impact of the VirusScan on-access scanner, which was observed utilizing up to 25 percent of CPU time and 220 MB of ram at random intervals. Since the MOVE agent offloads this activity to the MOVE Antivirus Offload Server, the impact on the desktops is drastically reduced.

Whether you look into MOVE or a competing product, it is worth your time to look at “new generation” antivirus solutions for your VDI deployments.

Additional References


· VMware View Architecture Planning

· VMware View Installation

· VMware View Administration

· VMware View Security

· VMware View Upgrades

· VMware View Integration

· VMware View Windows XP Deployment Guide

· VMware View Optimization Guide for Windows 7

· vSphere Installation and Setup Guide

· Anti-Virus Practices for VMware View

· VMware KB Article 1027713


· McAfee MOVE Antivirus 2.0.0 Product Guide

· McAfee MOVE Antivirus 2.0.0 Software Release Notes

· McAfee MOVE Antivirus 2.0.0 Deployment Guide