Recently I have been working on a performance scan for a customer. The customer wanted to have a newly built XenApp 7.6 environment validated. Ofcourse I used Login VSI to do the task at hand. While starting the validation, the customer expected to reach about 80 concurrent users on one physical host (with 3 virtual XenApp servers on it).

After getting VSI to run in the environment I started a first small test, with 30 users to see what the enviroment did.

BadAntiVirusConfig

Bad antivirus configuration

 

After seeing this test and reaching VSI max at 25 sessions (which comes to 8,3 users per XenApp server) I went back to the customer and told them my findings. The first thing I noted in the analyzer was that the IO baseline was high as they were on an all flash environment. So I suggested they have a look at the anti-virus configuration and especially the exclusions.

Turned out the antivirus configuration just didn't get applied. A next test we made sure antivirus was disabled on the machines and ran the same test, didn't reach VSI max on that. So I ran a test with 100 users. With the followin result:

GoodAntiVirusConfig

Good antivirus configuration

 

I was able to run 88 users without a problem on the servers (got a few stuck sessions because of an un-reliable outlook plugin making outlook crash).

The conclusion of the story. It is very important to have a good antivirus configuration for your VDI/SBC environment. Not only will it benefit the user density on your environment, it will also benefit the user experience on the environment.

 

Write comment (2 Comments)

In the previous post about the workplace and profiles (Workplace and Profiles) I spoke about the spoof profile executable I created. After that post I received a few questions about what the executable does. This post is to explain the working of the executable.

First of all, the program determines the SID of the user. The SID then is used to find the corresponding registry hive under: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList it will then change the value of state to 644 which will trigger the User Profile Service to delete the profile when  the users logs off.

This way you can use local profiles instead of a mandatory profile which will save you in:

  • Time creating a mandatory profile
  • Update your mandatory profile after windows updates (because basically what is trapped in the mandatory profile won't be targeted at windows update)
  • Advanced configurations (it will work out of the box)

 

Write comment (0 Comments)

Workplace and profiles

Working with Citrix XenApp, Microsoft Remote Desktop Services, or other types of workplace can be challenging when it comes to managing profiles. Most of the times mandatory profiles are used in these types of environments, but every time a user logs off their settings are flushed. Users are keen on there settings so there comes user profile visualization in to play. Tools that can virtualize user settings are Microsoft UEV, Appsense, VMWare UEM and RES Workspace Manager.

Since I like to work with local profiles instead of mandatory profiles (the fact that I don't have to update my profile after several Windows updates) I have to make sure that profiles are deleted after a user logs off. To do so, we have to trick Windows into believing the local profile is a guest or temporary profile.

In the past I always used a Powershell script to trick windows to believe the profile is a guest or temporary profile. Since Powershell isn't that quick I have created an executable made in C# which does it's work quicker. This article describes how to use the executable in RES Workspace manager. But I will also give some pointers on how to use the executable with other means.

Add to Workspace Manager

Download the attached zip file. Extract it and add the executable to the custom resources in RES Workspace Manager. You can place the executable in the root or in a separate folder of the custom resources.

Now the executable will be pushed to all the agents. It's time to create a logoff task. Head to Composition>Actions by Event > At Logoff

Right click in the actions tab and click New.

Configure the task as shown in this picture:

LogoffTask

 

 

 

Now the logoff task is in place, we have to configure a GPO with the following settings:

ProfileClean

 

Now that the GPO is created link it to the correct OU's and test out your local profiles in combination with RES WM. Look on the target machine to see if the profile get's deleted.

Using other types of management

When not using RES Workspace Manager as profile management tool. You still are able to use the executable. Only thing is that a user doesn't have the rights to edit the registry. That's why I recommend making a Group Policy (Machine\Policies\Windows Settings\Security Settings\Registry) to enable domain users to edit MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. That way when the user logs off the profile state gets set to the correct value and the profile will be deleted.

Please leave a comment if you have something to say about this article, or if you want to say thanks or discuss.

Write comment (0 Comments)

LabCreate a Lab environment

Currently I am creating and deleting AD pretty often, because I am trying out stuff in my Lab environment. Too reproduce the same enviroment I created the same OU's, users and groups everytime, by hand. This post is about how I create a lab environment.

So I created a powershell script to create the Lab environment Also created a powershell script to delete the entire environment from an existing AD and leave the rest intact, just if you need a "Lab environment" in an existing AD and want to delete afterwards.

The zip file containing the both powershell scripts are located in the download section of this site or attached to this post. All you have to do is edit the variable $BaseDN to represent your Active Directory domain.

At a customer we are using App-V 5.0 and RES Workspace Manager on XenApp 7.6 with Windows Server 2012 R2. For App-V the full infrastructure is in use. We wanted to make it possible for users to do an publishing refresh App-V applications without having them enter powershell commands or having them to logoff and logon. After the publishing refresh the script will initiate a workspace refresh.

I created an application with the following Settings:

Application: Refresh App-V Applications
Command line: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Working directory: C:\Windows\System32\WindowsPowerShell\v1.0\
Parameter: "C:\PROGRA~2\RESSOF~1\WORKSP~1\Data\DBCache\Resources\custom_resources\Scripts\RefreshAppV.ps1"

The content of the ps1 file is the following:

import-module appvclient
Sync-AppvPublishingServer -ServerId 1
#get-appvClientPackage
& "C:\Program Files (x86)\RES Software\Workspace Manager\pwrgate.exe" -2

 

The PS1 is placed in the custom resources in a folder called Scripts. Now when a user clicks the application, first there will be a sync between the client and the publishing server, after that process has completed a workspace refresh will be initiated.

Write comment (0 Comments)