Working on testing app-v packages using Flexera AdminStudio test machine facility (quite nifty actually) and by default was picking up errors using the App-v launcher relating to the app-v client service not being started. Manually starting the service didn’t bring any joy (another error with a -214 code).
Fix for this was simple enough in the end, seems even more than ever powershell needs to be invoked for more and more activities and this is no different. To enable simply go into powershell and type enable-appv like so and it will start up and set the service to automatic and your good to go
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.