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
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.
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:
- Create the folder C:\AppvLogs.
- 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”/>
- Restart the Broker service to start logging.
To enable VDA logs:
- Create the folder C:\AppvLogs.
- 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”/>
- Uncomment the line and set the value field to 1: <add key =”EnableLauncherLogs” value=”1″/>
- Restart the machine and logging should be working
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.
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
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):
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:
Good to see MS taking note of these “softer” type failure scenarios that occur more often in the VM space.
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.