For reference I would like to point out an recent article from the MS Performance Team.

This one can be quite interesting if you troubleshoot print spooler problems in your environment. Fortunately these kind of problems are not happening that often nowadays, but often enough to keep it in mind:

Microsoft Fixit for Printing @ Ask the Performance Team

Yesterday I stumbled over the following website while I was searching for Powershell WMI Eventing.

You can find all sessions from their event in January as video to see them online and for free. I found them quite useful (haven’t seem them all yet).

Here is a link listing all available sessions:
NIC 2012 Program

If you are interested in WMI Events have a look to these sessions:
Thomas Lee: An introduction to WMI And PowerShell
Thomas Lee: WMI Eventing with PowerShell

Today I just want to share an easy way (which I actually most liked) on how to delete DigiNotar’s Root certificates from your Windows “Trusted Root Certification Authorities” certificate store:

certutil -delstore authroot “c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c”
certutil -delstore authroot “43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3”

Sidenote: certutil.exe is included starting from Vista and Windows 2008 (for older OS’s you need to download it from Microsoft.)

• A good source including the tip above can be found here: Protecting yourself from attacks that leverage fraudulent DigiNotar digital certificates.
• Original Microsoft Security Advisory (2607712): Fraudulent Digital Certificates Could Allow Spoofing.
• If you like to know some powershell code the get similar things done have a look here (example of powershell code to manage the cert store): Microsoft Security Advisory “DigiNotar” (2607712) Removal.
• If you are even more interested into more details; browse here: DigiNotar breach – the story so far.

Update

Good news for those who waited to implement the change. There is now an official Microsoft update available:

http://support.microsoft.com/kb/2607712

As you might heard or experienced before, it is sometimes annoying to have the Adobe Reader and Adobe Acrobat installed on a terminal server at the same time. In this case you have to decide which program is responsible to be used as the default PDF viewer.

While this question can be managed easily through file type associations, I am focusing on similar problem today.

I would like to share how I solved a problem regarding the PDF plugin for Internet Explorer, as this is managed through different registry keys than known from file type associations.

Example

The following registry key is controlling which program is used to show PDF files within Internet Explorer (integrated view through plugin).

[HKEY_CLASSES_ROOT\Software\Adobe\Acrobat\Exe]
@="\"C:\\Program Files\\Adobe\\Reader 9.0\\Reader\\AcroRd32.exe\""

The problem: Different requirements for two web based applications

In my case one applications had a need for the Adobe Reader while another application required the Adobe Acrobat program as PDF viewer. As the key above was a system key, I had no idea how to handle the problem at the first time.

The objective: Exceptions for a specific user group

The aim was to have the Adobe Reader as system default, while some specific users should get a different configuration. Virtualization was not an options for me, because this felt unnecessarily complex and both programs were already installed on my servers.

The solution: Deploy configuration on user level

I found out that there is a rare know feature, which I am using now.

For the registry key located under HKEY_CLASSES_ROOT there is a counterpart within the user part of the registry (HKEY_CURRENT_USER).

HKEY_CLASSES_ROOT\Software –> HKEY_CURRENT_USER\SOFTWARE\Classes\Software

As far as I know this key is always queried before the system part is used. I just had to make sure, that my target users are getting the Adobe Acrobat configured here (e.g. through logon script).

Example:

[HKEY_CURRENT_USER\SOFTWARE\Classes\Software\Adobe\Acrobat\Exe]
@="\"C:\\Program Files\\Adobe\\Acrobat 8.0\\Acrobat\\Acrobat.exe\""

Since yesterday I noticed that there is an existing problem when you run a terminal server farm within the following environment.

• Windows 2008
• Multi-Language Support Enabled
• McAfee VSE 8.7
• McAfee Patch Level 4
• Terminal Services installed.

Problem

Quote from https://kc.mcafee.com/corporate/index?page=content&id=KB70384&cat=INTERNAL_CATEGORIES&actp=LIST:

“A blue screen error occurs sporadically when VirusScan Enterprise 8.7i with Patch 4 is installed on systems with Windows 2008 and terminal services such as Citrix terminal services or Windows Vista with Fast-User-Switching and where multi-language support has been enabled.”

I found out that this problem is already known for a while. You can find more details in the knowledgebase from McAfee: Bugcheck 0×5 INVALID_PROCESS_ATTACH_ATTEMPT.

Last update of this article was December 09, 2010. The only workaround available is to downgrade the McAfee Engine back to Patch Level 3.

Update (3th of February 2011):

There is now a hotfix available to solve the problem. Please find more details here: https://kc.mcafee.com/corporate/index?page=content&id=KB70384

In this article I am going through my experience with Citrix XenApp 6 Published Application management using PowerShell scripts.

First off all I need to admit that I am very excited about the new scripting interface provided by XenApp 6. With just a few commands you really can create something powerful. Compared to the old MFCOM interface it feels like a really major upgrade and to me it is one of the most liked feature they introduced to their new Xenapp version.

Assumptions

As I am already managing my published applications using MFCOM scripts, I had a clear picture of what to achieve with the new PowerShell commands.

Here is a list of things I wanted to get done in my XenApp 6 farm:

• Create published applications.
• Update existing published applications.
• Remove published applications.
• Create WorkerGroups as needed.
• Assign WorkerGroups to published applications.
• List all applications in the farm.

Fortunately I am happy with just these few tasks. There are much more possibilities. I focus on the most changing part of the farm configuration: Applications… they are created, changed and deleted while the rest of the configuration is very static.

High Level Script Workflow

Let me explain my current script workflow before I go into code details.

Example Citrix PowerShell Commands

Load the PowerShell snapins

# Load the snapins
Add-PSSnapin citrix* -ErrorAction SilentlyContinue

First of all you have to load the Citrix snapins into your current PowerShell session. I have added “-ErrorAction SilentlyContinue” because I am calling my script several times without checking if the snapins are already loaded (actually I don’t know how to do this). Omitting these parameters would lead to an exceptional error message.

Create list of all existing Citrix farm applications

# List all applications
Get-XAApplication | foreach { "$($_.FolderPath)/$($_.DisplayName)"}

This command creates a list with the following format:

• Applications/Programs/Microsoft Office 2010/Microsoft Excel 2010
• Applications/Programs/Microsoft Office 2010/Microsoft OneNote 2010
• Applications/Programs/Microsoft Office 2010/Microsoft Winword 2010

In my case I needed to extract the FolderPath and DisplayName because my reference list is in the same format.

Remove Published Application

$BrowserName = “Notepad”
Remove-XAApplication $BrowserName

Removing an application is very simple. Just provide the unique BrowserName of the applications.

Manage WorkerGroups

$WorkerGroup = “Silo1”
Get-XAWorkerGroup $WorkerGroup –ErrorAction SilentlyContinue

The Get-XAWorkerGroup command is just a check to find if I need to create the WorkerGroup or not, that is why SilentlyContinue is included again.

$WorkerGroup = “Silo1”
New-XAWorkerGroup -WorkerGroupName $WorkerGroup

These lines simply create the WorkerGroup.

Manage Published Applications

During the development phase of my scripts to manage published applications via PowerShell I found out that I need to support six different scenarios resulting in a different set of parameters.

• Create(1) or update(2) a published application using WorkerGroups
• Create(3) or update(4) a published Desktop using WorkerGroups
• Create(5) or update(6) a published Desktop using named Servers (ServerNames)

The following code examples show which parameters to use for the mentioned scenarios.

Example variables

$EncodedIconData = Get-CtxIcon "C:\Windows\notepad.exe" -index 0
[string]$DisplayName = "Notepad"
[string]$BrowserName = "Notepad"
[string]$CommandLineExecutable = "C:\Windows\notepad.exe"
[string]$WorkingDirectory = "C:\Windows"
[string]$FolderPath = "Applications/Programs"
[string]$ClientFolder = "Programs"
[string]$StartMenuFolder = "Programs"
[string]$WindowType = "95%"
[string]$WorkerGroupNames = "S1"
[string[]]$ServerNames = "Server1"
[string[]]$Accounts = "contoso.com\Domain Users"

1. Create a published application using WorkerGroups

# create new application
New-XAApplication -EncodedIconData $EncodedIconData -ApplicationType "ServerInstalled" -WorkerGroupNames $WorkerGroupNames -BrowserName $BrowserName -Enabled $TRUE -Accounts $Accounts -WorkingDirectory $WorkingDirectory -CommandLineExecutable $CommandLineExecutable -FolderPath $FolderPath -ClientFolder $ClientFolder -StartMenuFolder "$StartMenuFolder" -WindowType $WindowType -DisplayName "$DisplayName" -Force -SkipPassThru
 

2. Update a published application using WorkerGroups

# set application
Set-XAApplication -EncodedIconData $EncodedIconData -WorkerGroupNames  $WorkerGroupNames -BrowserName $BrowserName -Enabled $TRUE -Accounts $Accounts -WorkingDirectory $WorkingDirectory -CommandLineExecutable $CommandLineExecutable -ClientFolder $ClientFolder -StartMenuFolder $StartMenuFolder -WindowType $WindowType
 

3. Create a published Desktop using WorkerGroups

# create new desktop
New-XAApplication -EncodedIconData $EncodedIconData -ApplicationType "ServerDesktop" -WorkerGroupNames  $WorkerGroupNames -BrowserName $BrowserName -Enabled $TRUE -Accounts $Accounts -FolderPath $FolderPath -ClientFolder $ClientFolder -StartMenuFolder $StartMenuFolder -WindowType $WindowType -DisplayName $DisplayName -Force -SkipPassThru
 

4. Update a published Desktop using WorkerGroups

# set application
Set-XAApplication -EncodedIconData $EncodedIconData -WorkerGroupNames  $WorkerGroupNames -BrowserName $BrowserName -Enabled $TRUE -Accounts $Accounts -ClientFolder $ClientFolder -StartMenuFolder $StartMenuFolder -WindowType $WindowType
 

5. Create a published Desktop using named Servers (ServerNames)

# create new desktop
New-XAApplication -EncodedIconData $EncodedIconData -ApplicationType "ServerDesktop" -ServerNames  $ServerNames -BrowserName $BrowserName -Enabled $TRUE -Accounts $Accounts -FolderPath $FolderPath -ClientFolder $ClientFolder -StartMenuFolder $StartMenuFolder -WindowType $WindowType -DisplayName $DisplayName -Force -SkipPassThru
 

6. Update a published Desktop using named Servers (ServerNames)

# set application
Set-XAApplication -EncodedIconData $EncodedIconData -ServerNames  $ServerNames -BrowserName $BrowserName -Enabled $TRUE -Accounts $Accounts -ClientFolder $ClientFolder -StartMenuFolder $StartMenuFolder -WindowType $WindowType
 

Complete Example to create a published application

# Load Snapins
Add-PSSnapin citrix* -ErrorAction SilentlyContinue

# Set application values
$EncodedIconData = Get-CtxIcon "C:\Windows\notepad.exe" -index 0
[string]$DisplayName = "Notepad"
[string]$BrowserName = "Notepad"
[string]$CommandLineExecutable = "C:\Windows\notepad.exe"
[string]$WorkingDirectory = "C:\Windows"
[string]$FolderPath = "Applications/Programs"
[string]$ClientFolder = "Programs"
[string]$StartMenuFolder = "Programs"
[string]$WindowType = "95%"
[string]$WorkerGroupNames = "S1"
[string[]]$ServerNames = "Server1"
[string[]]$Accounts = "contoso.com\Domain Users"

# Create WorkerGroup
New-XAWorkerGroup -WorkerGroupName $WorkerGroupNames 

# Create applications
New-XAApplication -EncodedIconData $EncodedIconData -ApplicationType "ServerInstalled" -WorkerGroupNames $WorkerGroupNames -BrowserName $BrowserName -Enabled $TRUE -Accounts $Accounts -WorkingDirectory $WorkingDirectory -CommandLineExecutable $CommandLineExecutable -FolderPath $FolderPath -ClientFolder $ClientFolder -StartMenuFolder "$StartMenuFolder" -WindowType $WindowType -DisplayName "$DisplayName" -Force -SkipPassThru
 

Lessons Learned

If you are new to Citrix scripting the following shared experience might be useful for you:

Browsername vs. Display Name

The Browsername parameter for some scripting commands is a farm wide unique name for an published application, while the Display name can be there twice. The Display name just has to be unique within the same application folder. Just keep this in mind while you script.

Published Application Icon

If you extract Icons using the Get-CtxIcon command you always should use the parameter “-index 0”.

I had some troubles not using this parameter at the beginning. Omitting this parameter will extract all available icon data from a given file. This possibly will cause a problem with the New-XAApplication command for unknown reasons. I guess that there is a limit on the input parameter.

Interesting resources

Here are some other web resources I found. It is highly recommended to install the Citrix XenApp 6 PowerShell SDK which includes the complete documentation of the scripting interface.

XenApp 6 PowerShell SDK: http://community.citrix.com/display/xa/XenApp+6+PowerShell+SDK

XenApp PowerShell SDK QA: http://community.citrix.com/display/ocb/2010/08/31/XenApp+PowerShell+SDK+QA

How to Install the Citrix XenApp 6 PowerShell Cmdlets: http://www.jasonconger.com/post/How-to-Install-the-Citrix-XenApp-6-PowerShell-Cmdlets.aspx

Today I faced a funny problem while implementing my logonscript for the terminal server. Normally I replace the default usrlogon.cmd script which resides in C:\Windows\System32 What I needed to realize soon is that citrix still uses 32-Bit programs in the background.

One example I had to learn the hard way is that the Citrix provided ctxhide.exe program is still compiled as 32-Bit program. As we already know there is a filesystem redirection in place which tells 32-Bit programs to find their “SYSTEM32” under C:\Windows\SySWoW64.

ctxhide.exe will use SySWoW64!

So, if you are running XenApp6 on Windows 2008 R2 (64-Bit) this results in a situation that the following path is used to execute the usrlogon.cmd script

C:\Windows\SySWoW64\usrlogon.cmd

This may get important if you are migrating to a 64-Bit platform like I do.

How to replace the standard usrlogon.cmd script?

Before I was able to replace the usrlogon.cmd script, I needed to take the ownership of the file. Otherwise the access will be denied by the system.

1) I used the following SetAcl command to set the owner of the file to the local Administrators group:

setacl -on "C:\Windows\SySWoW64\usrlogon.cmd" -ot file -actn setowner -ownr "n:S-1-5-32-544;s:y"

2) Than I give System and the local Administrators group full access, and local Users read and execute permission:

setacl -on "C:\Windows\SySWoW64\usrlogon.cmd" -ot file -actn rstchldrn -rst "dacl,sacl" -actn setprot -op "dacl:p_nc" -actn ace -ace "n:S-1-5-32-544;s:y;p:full" -actn ace -ace "n:S-1-5-18;s:y;p:full" -actn ace -ace "n:$group;s:n;p:$Permission" -actn clear -clr "dacl,sacl"

By the way: There is an old citrix knowledgebase article which already describes this behaviour.

Additional Information

http://support.citrix.com/article/CTX108901 (Usrlogon.cmd Does Not Execute on Presentation Server for Windows x64)

Today I had a look on how to prepare my environment for Windows 2008 R2. It seems there are some changes required to adopt my current unattended installation. The following lines represents my first analyze I did on my existing packages.

My starting point is my current full automated server installation based on Windows 2008 running with XenApp 5. So, I just took my packages and reviewed them with the following questions in mind:

• Which install routines can be reused without any modifications?
• Which install routines need to be modified?
• Which install routines are obsolete?

Analysis results

Windows Update Agent

Old

I used to install the current Windows Update Agent with the following command:

	windowsupdateagent30-x86.exe /WuForce /Quiet /NoRestart

New

There is a dedicated client available for 64-Bit based systems; the setup is the same

	windowsupdateagent30-x64.exe /WuForce /Quiet /NoRestart

Windows Terminal Services

Old

With Windows 2008 I used the following commands to install the terminal services:

servermanagercmd -install Application-Server
servermanagercmd -install AS-Ent-Services
servermanagercmd -install TS-Terminal-Server

New

With Windows 2008 R2 it is still possible to use these commands. But if you use the ServerManagerCMD you will get the following message:

"Servermanagercmd.exe is deprecated, and is not guaranteed to be supported in future releases of Windows. We recommend that you use the Windows PowerShell cmdlets that are available for Server Manager."

Also features were renamed. I am using now the following Powershell commands to prepare my servers for XenApp 6

import-module servermanager
add-windowsfeature application-server
add-windowsfeature RDS-RD-Server

If you install the Remote Desktop Services the Internet Explorer Hardening feature will automatically being disabled for users. This was not the case with Windows 2008

.Net Framework 3.5

There is no need any more to install the .Net Framework 3.5 separately. The framework is now a feature of windows and gets automatically installed if you install the Remote Desktop Services feature.

If you install Microsoft you may recognize that the start menu does not contain the shortcuts you maybe expected. As you can see target is empty.

This is very annoying if you need the full path for publishing in Citrix XenApp farm or to build up your custom start menu.

Here is a list of Microsoft Office 2010 programs and their path to the executable in the file system:

…

Why do I write about this?

The answer is simple because I already looked up this information several times in my life to get to know what the executable name for an office application is. Maybe I should do more brain training instead of blogging about .

Photo by visulogik

Below you find a small compilation of things you should know when you work with 64-Bit the first time. Having this in mind can help you fighting against applications phenomena.

• System files and windows programs of the 64-Bit OS are still located in C:\Windows\System32.

• A 32-Bit program that accesses C:\Windows\System32 will be redirected to C:\Windows\SysWOW64 in background (the software does not know).

• Some windows integrated programs exist as 32-Bit and 64-Bit version. Notepad.exe for example can be found in C:\Windows\SysWOW64 and C:\Windows\System32.

• 32-Bit Programs will be installed to C:\Program files (x86).

• Registry Class-ID’s are redirected to HKLM:\Software\Wow6432Node\Classes\CLSID.

Remember: Only 64-Bit programs see the real environment as it is. 32-Bit programs only see a simulated environment through redirection mechanisms. Pay attention to the points above if you do critical stuff with a 32-Bit program.

This is just a small help.

Please see these links for more background information:

64-Bit Windows (x64)