Project VRC released new white paper about impact of antivirus on VDI
Amsterdam, 17 January, 2013 – Project Virtual Reality Check (Project VRC) is pleased to announce the release of the long awaited ‘Phase V’ white paper which provides independent insights in the impact and best practices of various antivirus (AV) solutions on VDI performance.
The R&D project ‘Virtual Reality Check’ (VRC) was started in early 2009 by the Dutch IT companies PQR (www.pqr.com) and Login Consultants (www.loginconsultants.com) and focuses on research in the desktop virtualization market. Several white papers were published about the performance and best practices of different hypervisors, application virtualization solutions and Windows Operating Systems in server hosted desktop solutions.
This new white paper contains the test results of the VDI performance impact of the antivirus solutions from three leading vendors: McAfee, Microsoft and Symantec.
“When VDI is implemented into production, performance is often a serious issue. A performance impact of up to 40 percent is not unusual after antivirus is installed.” said Jeroen van de Kamp, CTO of Login Consultants “While this aspect has been less of an issue with PC’s or laptops, with performance sensitive environments like VDI it means you need to invest in servers and storage. This was the reason for us to investigate, and provide objective data about, the exact impact of antivirus on VDI”.
“It is important to highlight the fact that Project VRC does not evaluate the quality of the security features of the different AV products, but only provides information about the impact these solutions have on VDI performance” said Ruben Spruijt, CTO of PQR “By testing and comparing different solutions and configurations we discovered the best practice to perform a pre-scan of the master image before it’s deployed. The effect is huge and therefore highly recommended”.
Another key finding published in the white paper is that antivirus off-loading architectures makes a big difference from a storage IO point of view, but not always from a session density point of view.
All Project VRC tests are performed with Login VSI (www.loginvsi.com), the industry standard benchmarking tool for VDI. This software tool simulates typical user workloads to objectively test the performance of VDI and Server Based Computing environments. The full test methodology is described in the white paper.
This and all other Project VRC white papers can be downloaded for free at www.projectvrc.com. To keep up-to-date with the latest developments you can follow Project VRC on Twitter @ProjectVRC.
PQR is the specialist for professional IT infrastructures with focus on safe and manageable availability of data, applications and workstations with optimal user experience. PQR provides its customers with innovative IT solutions that ensure optimal application availability and manageability, without complex processes. Simplicity in IT, that’s what PQR stands for.
PQR focuses on four main themes:
- Data & System Availability
- Application & Desktop Delivery
- Secure Access & Secure Networking
- Advanced IT Infrastructure & Management
PQR was founded in 1990, is located in De Meern, The Netherlands, and has over 100 employees. In the fiscal year 2011/2012, PQR achieved a turnover of € 94.9 million and a net profit after tax of € 4.6 million. For more information visit www.pqr.com
About Login Consultants
Login Consultants is an independent international IT service provider specialized in End User Computing. We help our clients in finding the optimal balance between IT control and end user flexibility. Our goal is an innovative and unique solution, which simplifies future change. Our success with our customers is built on the quality of integration combined with a smart migration approach and the manageability of the solution after deployment.
Login Consultants has an experienced team with over 140 consultants in The Netherlands, Belgium and Germany. Our consultants have accreditations from Microsoft, Citrix and VMware, and are regularly invited to speak at national and international events. They are involved as experts in online and printed IT publications and actively participate in relevant technical blogs. For more information visit www.loginconsultants.com
About Login VSI
Login Virtual Session Indexer (Login VSI) is a vendor independent benchmarking tool to objectively test and measure the performance and scalability of Virtual Desktop Infrastructures and Server Based Computing environments by simulating unique user workloads. Leading IT-analysts recognize and recommend Login VSI as the de-facto industry standard benchmarking tool for VDI and SBC. Login VSI can be used to test VMware View, Citrix XenDesktop and XenApp, Microsoft Remote Desktop Services or any other Windows based hosted desktop solution. For more information visit www.loginvsi.com
At the moment I work at a company with about 8000 to 9000 workstations. A couple of users called in an issue that they had trouble logging in into Windows 7. Once in a while they got the following error message during the logon process.
“Windows could not connect to the Event Notification Service service. Please consult your System Administrator”
Only one or more reboot(s) seemed to bypass the error. This was not an acceptable situation and I was asked to look into this problem.
- Windows 2008 R2
- Window 7
- SCCM 2007 R2
- RES Workspace Manager 2011
- App-V 4.6 SP1
Underneath a screenshot of the error message:
After checking the event viewer I noticed that not only the “System Event Notification Service” was failing but also several other services failed to start. Underneath a list of services that are involved.
- Certificate Propagation
- Extensible Authentication Protocol
- Group Policy Client
- IKE and AuthIP IPsec Keying Modules
- IP Helper
- Multimedia Class Scheduler
- User Profile Service
- Task Scheduler
- System Event Notification Service
- Shell Hardware Detection
- Windows Management Instrumentation
With the knowledge that not only the “System Event Notification Service” service was failing to start I searched the web for a solution. I found several articles but they didn’t solve my problem. Than I stumbled onto the following Hotfix:
This hotfix solved my problem. But in the meanwhile several users were still experiencing this problem. Due a backlog on the change management side, it would take a while to get this hotfix in production. I decided to look for a workaround for the customers who were experiencing this problem more frequently. It seemed, like described in the article, that the “Microsoft Virtualization client” had something to do with it. I quote:
“Cause: This issue occurs when a new drive is added to the system while background services are still starting. The most common example of this is with Microsoft Application Virtualization Client. When this service starts, it creates a virtual drive. When this drive is created during system startup, the Server service may crash the shared service host process. This process contains other services which are important for completing user logins. When these services fail at startup, a blue or black background image is displayed instead of the user’s desktop.“
When trying to find a workaround I found that delaying the startup of the “Microsoft Virtualization Client” service seemed to work. This should give the other services time to start-up. It’s a quick and dirty method but it did solve the problem for the users who were experiencing this problem on a frequent base. We decided to use it as a temporally workaround until the hotfix was applied.
The hotfix is also applicable for Windows Server 2008 R2 in case you are experiencing the same issues on a server.
At the moment I am working in an environment where App-V is integrated in SCCM 2007. To launch an App-V application the “Vapplauncher” is used. This week I have been asked to package an application with the following requirements.
The application must be able to start from a Scheduled Task and External Application.
- The application must start with different parameters.
- The parameters can change every month and this should be done by the “Super user” (Which has no access to App-V / SCCM)
Starting the App-V application from a schedule or external application is just pasting the Vapplauncher command line into it. However, the Vapplauncher doesn’t accept any parameters. This is why you have to create a extra OSD with the parameters in it. This means that the “Super user” has to change this OSD each month and deploy it through SCCM. Of course this was not an option because of the rights.
- Start the application with the parameters through: C:\WINDOWS\system32\CCM\VAppLauncher.exe /launch “MyApp”
- The user must be able to change the parameters each month without having to change the OSD or having special rights.
- Create a networkshare where the user has enough rights to change/write files
- Place a *.txt file in the share containing the parameters
- Create a PowerShell script (or more if needed) in the share which can do the following:
- Get the content of the *.txt file
- Start the application with the parameters found in the *.txt file which is edited by the user
- Create an OSD to start the PowerShell script
- Give the user the command line to start the OSD so it can be used in a schedule or External application
Components of the solution:
*.txt file for user: G:\MyApp\Test\MyApp_parameters.txt
PowerShell script: G:\Myapp\test\Script\Start_Myapp.ps1
App-V package: With at least one OSD that starts the application with the powershell script
The powershell script:
#Filing some Variables
$ParametersTXT=Get-Content "G:\MyApp\Test\MyApp_parameters.txt "
#Some arguments are fixed this will be combined with the Parameters from the TXT file
$StartMyAppArguments +="/DSN=Test /CMD=ABC "
$StartMyAppArguments +="/TXT=" + $ParametersTXT
#Start the application with arguments
&$StartPath -p $StartMyAppArguments
These are the basics of the script. Of course you should adept it to your needs with logging and checking on existing files etc. But now you will have a start.
This is the starting line you should use in the OSD:
parameters="-file G:\Myapp\test\Script\Start_Myapp.ps1" FILENAME="%CSIDL_SYSTEM%\WindowsPowerShell\v1.0\powershell.exe"
The command line to start the application is:
C:\WINDOWS\system32\CCM\VAppLauncher.exe /launch " MyApp-StartbySchedule”
Thank you for reading. I hope it will be useful for you. If you have any comments or questions you can use the comments underneath or the PM system to ask questions.
Not to long ago we had some issues (re)deploying Windows 7 (including the baseline) on our client systems. One out of three systems failed during (re)deployment. At first we thought it was because the systems were not removed correctly from SCCM before redeployment. Further investigation told us that the deployment also failed on new systems and systems which were correctly removed from SCCM before redeployment.
- Windows 2008 R2
- Window 7
- SCCM 2007 R2
- RES Workspace Manager 2011
- App-V 4.6 SP1
CcmExec.log logged the following:
“Error unregistering notification query CcmExec“ occurs after a restart initiated by the installation of the App-V client. It seems that CcmExec (SMS Agent Host service) is having trouble to start. After a while it times out and the (re)deployment fails. The restart which is needed after the installation of the App-V client is the first restart initiated by an application after the windows installation. It could be possible that this error also occurs after other installations where a reboot is needed. Unfortunately we haven’t run tests on this, we only have one installation which needs a reboot during this phase.
By delaying the auto startup of the CcmExec service we solved the (re)deployment issues in this case. The CcmExec service will start after all other services who are configured as “Automatic” startup. Normally this is used to shorten the boot time but in this case it also helps us preventing (re)deployment failures. Right before the installation of the App-V client we added a “Run command line” to the task sequence as follows.
Type: Run Command Line
Name: Delay startup CCMexec service
Description: Delay CCMexec (SMS Host Agent) service
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CcmExec /v DelayedAutostart /t REG_DWORD /d 00000001 /f
Before the last action of our task sequence will take place, in our case a last reboot to complete the deployment, we added the following “Run Command Line”.
Type: Run Command Line
Name: Automatic startup CCMexec service
Description: Sets CCMexec (SMS Host Agent) service on automatic start without delay
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CcmExec /v DelayedAutostart /t REG_DWORD /d 00000000 /f
This was our solution for the (re)deployment problem we encountered and hopefully it will help some of you who experience the same problems. If you have any comment or questions you can post them down below in the comment section.