Category: Microsoft

Windows VDI environment? getting poor performance on SCCM downloads?

Recently been tasked with migrating a fair ton of apps from Win7->10. One of the challenges in this space is testing. Previously with Windows 7 the guys worked on static persistent VM’s rolled out to testers to run their updated app through it’s paces. Few obvious problems with this approach

I) Quite a bit of VM admin to do – clean up post test of apps

2) Quite a bit of email admin to do – separate mails tailored for specific app owners detailing their specific machine to test etc

Luckily things have moved on a bit most importantly regards “delivery” of the apps. By that I mean previously was hamstrung with only allowing a VDI-type scenario being of use to cover app-v sequenced apps as they where using the “follow-the-user” model (user added to SCCM user collection and deployment type set to include VDI. As such at the time experience was limited with app-v which meant a VDI solution wasn’t practical for testing as vast majority of apps where MSI’s.

To that end we have been able to get over that hurdle by publishing the MSI’s as applications in SCCM rather than packages this gives us the flexibility to use the same follow-the-user approach as with app-v sequences. That being so a Win10 VDI then would have merit.

So recently got going on standing one up (XenDesktop 7.13 back-end). Tested adding a few of the team to a few random app-v sequences / MSI’s applications and noticed horrible download performance for all our apps/packages in Software Center. For example a 200mb MSI took 40 minutes to download.

Issue was put down to the BITs client configuration. For all workstations in general in an environment there is a cap on download speed. Enclosed illustrates what’s in my lab environment

as you can see there is cap’s on performance at certain times of the day. That makes sense for the general workstation population in an environment particularly for remote users over VPN as SCCM does not have an elegant way to identify a user that roams between local and VPN.

As such of course for VDI its not a requirement so in order to switch off I inserted a GPP into my GPO to set no limit on download rate. Registry key is called EnableBitsMaxBandwidth and set to 0 (located under HKLM \Software \ Policies \ Microsoft \ Windows \ BITS)

once I place was rocking and rolling and downloads flew along

PVS write cache filling up? handy filter in Procmon to give a clue as to what’s causing it

So of course with write cache filling up issues no simple way to tell what’s going on. Needless to say like most quirks that happen in Windows the sysinternals tools can come to you rescue.

Recently started work on a windows 10 PVS image and after about 10 minutes the write cache would fill up.

So using Procmon (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx) was able to determine what was going on.

In order though to filter out the extraneous stuff found the following 2 filters gave me info on the offenders.

To do click Filter and filter out everything except write activity by making two filters as follows:

Operation begins with WriteFile Include
Operation begins with WriteConfig Include

and you’ll be on our way.

 

Enabling logging for troubleshooting app-v issues in your citrix environment

When troubleshooting App-v issues in your citrix environment one of the first usual port of calls will be to enabling logging.

To enable Studio and VDA logs used for App-V, you must have administrator privileges. You will also need a text editor such as Notepad.

To enable the Citrix Studio logs:

  1. Create the folder C:\AppvLogs.
  2. Navigate to C:\ProgramFiles\Citrix\StudioAppVIntegration\SnapIn\Citrix.Appv.Admin.V1. Open CtxAppvCommon.dll.config in a text editor and uncomment the line: <add key =”LogFileName” value=”C:\AppvLogs\log.txt”/>
  3. Restart the Broker service to start logging.

To enable VDA logs:

  1. Create the folder C:\AppvLogs.
  2. Go to C:\ProgramFiles\Citrix\ Virtual Desktop Agent. Open CtxAppvCommon.dll.config in a text editor and uncomment the following line: <add key =”LogFileName” value=”C:\AppvLogs\log.txt”/>
  3. Uncomment the line and set the value field to 1: <add key =”EnableLauncherLogs” value=”1″/>
  4. Restart the machine and logging should be working

Remote nano server admin : quick few commands needed to get you access to box

Recently was given a project with a proof of concept involving the use of Windows 2016 nano servers (don’t even know if that’s there official title :)). Anyhow as not quite your conventional windows servers took a wee bit of lurking to find what i needed to get access.

Bit of background:

So Nano server comes with a rebuilt subset of Windows Powershell and they’ve called it Core PowerShell. Feature-set wise seems to have everything i need, full remoting capability, language compatibility etc.

As it does come with Windows Powershell Remoting it indeed is our gateway to access the server.

Requirements

i) Need to have administrator level privileges to the Nano Server

ii) Add its IP to the managed machine’s trusted hosts(assuming 192.168.1.1 is the Nano Server’s IP) to do

PS c:\> set-Item WSMAN:\\localhost\Client\TrustedHosts “192.168.1.1”

Next you can start an interactive remoting session:

PS C:\NanoServer> $ip = “192.168.1.1”

PS C:\NanoServer> $user = “Administrator”

PS C:\NanoServer> $Enter-PSSession -ComputerName $ip -Credential $user

After that you are good to go, can run commands as if you were entering directly on the nano server console eg

[192.168.1.1]: PS c:\users\test\documents> ipconfig

To get the full list of commands available

[192.168.1.1]: PS c:\users\test\documents> Get-Command -CommandType Cmdlet

 

Handy URL’s relating to 2012 r2 RDS environments

2 areas’s that always need some TLC are patch management and AV. Enclosed couple of URL’s relating to them:

For patch management (covering various RDS roles):

Recommended hotfixes and updates for Remote Desktop Services in Windows Server 2012 R2

For Anti-virus

https://support.microsoft.com/en-us/kb/822158

 

 

 

W2k16 clustering – transient failure monitoring improvements

Recently came across a good MS blog article that covers some of the improvements made in VM monitoring at a cluster level in Windows Server 2016:

Virtual Machine Compute Resiliency in Windows Server 2016

Good to see MS taking note of these “softer” type failure scenarios that occur more often in the VM space.

 

Nifty new MS cluster feature (2016 Server tech) – configure your own witness in the cloud

An interesting feature within W2k16 within the clustering framework is the cloud witness. Quorum maintenance being one of the most important parts of any cluster design. With DR can be a design challenge as MS recommend that the quorum is located in a 3rd data center. As a lot of companies operate using 2 data centers this can pose a problem.

With the tech preview edition of 2016 it introduces a new feature called the cloud witness that looks to address this problem.

Creating one is simple and via the usual means to create a quorum using the Cluster Quorum wizard. The pre-requisites are straightforward enough too. Need:

i) An active Azure subscription

ii) Storage account

To launch the wizard:

i) Right-click the server in the Failover Cluster Manager

ii) Point to More Actions

iii) Select Configure Cluster Quorum Settings

iv) Select the Quorum Witness option

v) Select the Configure a Cloud Witness option

vi) On the next page provide the name of your Azure storage account, copy the key from the Azure Portal to the clipboard and type the Azure service endpoint

When the wizard is completed you’ll see the cloud witness displayed in the Cluster Core Resources pane in the Failover Configuration Manager snap-in.