Software Deployment

What about during uninstall of an application - how would current user keys get removed.

We use roaming profiles in our environment - windows 2003 server, citrix ps4.
We install via command line (change user /install, install application (msiexec ....), change user /execute)
We uninstall via Add/Remove (which should automatically change to install mode)

Right now our current user keys stay in the users' profiles - sometimes newer versions of applications end up reading these keys and don't work. We end up having to run custom logon scripts to remove those keys from users' profiles - more slowdown at logon time.

Any suggestions?

Well you basically have that issue identified and the solution is to manage the removal of settings per profile. Unfortunately something has to run per-user. Having a logon script clear out old settings is one way or using a ActiveSetup command (do not use for seamless apps) to clean up the profile when the app is removed is another (you have to make sure that the remove runs before the new version does it's setup). Most sites I go to have some sort of mechanism that will do profile setup outside of using the shadow key so that they can program in a purge of profile settings if necessary into the profile setup. I've seen batch files, vbscripts or even WiseScript EXEs to perform this function. Basically things get very creative and it is up to you what you see fit as a solution. I am personally a fan of flex profiles with Citrix and one option there would be to run a batch file to delete the flex profile settings for the application to be upgraded out of each user's profile on a file server just before you upgrade the application on your Citrix farm. With the flex settings deleted the profile would be in a semi virgin state for the new application settings. If logon times are a concern then take a very close look at Flex Framework.

You still have to figure out how you want to populate the user profile but I think from this thread you can see that there are many different ways to get the job done.

Hello,

we are using the visionapp platform suite to deploy Citrix Servers!

http://www.visionapp.com

Regards
Uwe

What about populating these HKCU settings via logon script for published apps?

-Dan

Since you are using Active Setup at least you know what you need to run. Sadly with Citrix the reduced shell gets rid of Active Setup process among other things but you can still work around it. Most companies that need this functionality usually use a multitude of home brew solutions. The most common is to have the shortcut in the Citrix console point to a batch file, VBScript or EXE that makes sure the user profile has been initialized for the app and then executes the sequence of events accordingly. I would have your user setup place a registry marker somewhere in HKCU so that if the user profile is reset the markers and the application settings make their way back into the user profile.

All, thanks for the replies.

uwemild - Sounds nice but I don't think we'll money to invest in any 3rd party deployment utilities unfortunately. I'll certantly have a read and suggest it though.

danr29 - Although this is a solution, it's not really one we wanted to use mainly because 1) A single logon script is used for the entire Citrix farm - the processing time would therefore grow as the number of Citrix applications increases which is not great from a user perspective. 2) Control and maintenance over the delivery of current user components is moved out of the installation routine / packaging team.

kkaminsk - The solution you state is one we have explored, where we created a wise script which performs it's own active setup type routine before executing the application. The published Citrix application then runs this wise exe. This becomes cumbersome if an app has multiple shortcuts - which isn't a show stopper but still a pain.

The main problem we have with this method is for applications that don't have any shortcuts, or applications to be installed on all Citrix servers. For example Adobe Reader - this needs to go onto all servers and has CU keys, but we can't expect users to have to run a shortcut once to get these delivered...

As you say, the solution is homebrew and varies from company to company. It maybe that we use a combination of this method and the logon script to achieve our goals.

It's a shame as Active Setup would have been a nice neat way of handling Current User components for all packages. For anyone interested, an explantion of why Active Setup doesn't run for published apps is below (which we obtained by raising a support call).

Thanks again. I'd be interested to hear any other suggestions / comments [:)]

Regards,
Rob.

Support call response:
--------------------------------------------
To answer your question regarding if Active Setup is supported for Seamless Applications,
I have to inform you that this will not run. I try to explain why.

If you logon to a Desktop, than one of the Files started by the OS is Userinit.exe.

This userinit.exe is responsible for starting the Shell, which provide you with the Desktop you see on the machine.

Active Setup, originally designed from Microsoft for the Internet Explorer is running in dependency of this shell from userinit.exe.

When you logon with a User the first time to a computer where Internet Explorer is installed, you can see this by the Popup appearing
with the “Internet Explorer is being configured”. That’s the Active Setup Part of Internet Explorer.

So in a published Desktop the Userinit.exe will be started from winlogon.exe, to provide you with your working shell.

In a published Application you don’t want to see the Desktop Shell, so the userinit.exe is not launched in there.

As a result also the Active Setup will not launch in a published Application.

You can reproduce this very simple by Installing Internet Explorer on a Citrix Server, publish it and than start it from a Client with a new User.

You will not see the popup with the “Internet Exploer is being configured”.

Also when you check the Session Processes in the CMC of the Citrix Server for this User you will see, that the userinit.exe is not launched.

So for this reason this is a work as design and Active Setup will not work with published Applications. Only published Desktop will work.
--------------------------------------------

Well if you are feeling up to the technical challenge my preference for user profiles on Citrix is flex profiles over a manditory profile.

http://www.brianmadden.com/content/content.asp?ID=315


More management for the administrator but way better than roaming profiles IMO. I want to write more but this is not a simple solution to implement. However if you feel like your enterprise has the skill to set this up and properly maintain it then you got yourself a nice tool in the Citrix profile war chest.

My bad, newer version is up here.

http://portal.loginconsultants.nl/forum/index.php?board=16;action=display;threadid=1144

There is a special set of keys under HKLM that allow all users logging into the machine to use the KHCU information in your package.

SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install

Under Install is where you would populate the HKCU keys, so for example you may have Install\Software\Microsoft. This key is the best key to use and sorts out all your HKCU problems :)

A quote from a Microsoft article I found:

***************

Installation
Application installation is different when Terminal Services is enabled in Windows 2000 Server. The registry and .ini file mapping support that is built into Terminal Services allows applications that were not originally designed to run in a multiuser environment to run correctly under Terminal Services. This means that users should be able to execute these applications simultaneously and save whatever preferences the application allows for each of them. Of course, each user must have a unique home directory. If no home directory is specified for a user by the administrator, the user's home directory defaults to his or her user profile directory, \Wtsrv\Profiles\Username.

To enable each user to retain individual application settings, he or she must have a unique copy of the appropriate .ini files or registry entries. To accomplish this, Terminal Services replicates the .ini files and registry entries from a common system location to each user as necessary. For .ini files, this means that the .ini files in the system directory (%systemroot%) will be copied to each user's Windows directory. For registry entries, the registry entries will be copied from HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows NT\CurrentVersion\Terminal Server\Install\Software to HKEY_CURRENT_USER \Software.

http://www.microsoft.com/technet/prodtechnol/Win2KTS/maintain/optimize/tsappdev.mspx

**********
Also another key I have found that is required in a Terminal server is the following:

SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\<EXE Name>

An example:
SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\WinFax

Name: Flags <DWORD>
Value: 1036

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

The link above points to the MS information about flags and the Compatibility key.

Not sure any of this information will help :)

Regards,
Paul

Hi Paul,

Thanks for the response. We originally wanted to avoid using the shadow keys to deliver current user registry entries do to issues that can arise with the way time stamping works: http://www.brianmadden.com/content/article/How-Applications-use-the-Registry-in-Terminal-Server-Environments-Part-2-of-3

A possible resolution is to use the tools (RDT.EXE / SDT.EXE) shown here http://www.brianmadden.com/content/article/Finally-Shadow-Key-Timestamping-Utilities-from-Microsoft and have them run on new servers before they go into production.

This is probably what we'll end up doing for CU keys. Still a bit crappy though...

Regards,
Rob.

Interesting discussion as I'm about to start designing a similar setup myself. Having designed mostly desktop solutions this saves me quite some testing as I've read up on Citrix and found the same limitations, and was about to start testing Active Setup as that seemed to be a natural solution.

One important point for me having a large base of already prepared XP/2000 client packages will be to limit the changes needed to have them work in a citrix/TS environment. Most of these already use Active Setup due to company standards.

At this point it seems smart to try and build a custom solution (sigh ..) that will actually parse the already existing Active Setup keys in a similar manner to Active Setup itself, but from a login script. Anyone gone this route? If it works out I'd be able to keep my "package once, use every(almost)where" dream a while longer (surely as long as noone mentions that .. that ugly V...a thing).

Another thing to test would be to try 2x Application Server and its publishing feature, to see if that leaves us at the same page. If it does I would be inclined to ask 2x to add Active Setup processing as a feature, it seems possible. They'd be all over that the minute they realize it'd give their customers something Citrix doesn't do :-)