thank youi for the answer above.
But I think Gertjan and I are looking for a document which in a technical way describes how to implement Ivanti DesktopNow in a environment running Citrix services like e.g. Provisioning Services, MCS, XenApp, XenDesktop, App Layering etc.
This is not the same scenario like running services on AWS or Azure and controlling those services using Desktop Now.
BTW: the press release mentions Ivanti DesktopNow Plus, the link is pointing to the standard DesktopNow website, is Ivanti DesktopNow Plus a different product or just a marketing phrase for the same product?
I have got in touch with one of my colleagues and asked them to get in touch directly.
I hope that helps?
Josef is completely right. DesktopNow is often used within Citrix environments and I'm surprised that there are so little complete and up to date resources about the integration of both software vendors. Contact is very nice and appreciated , but I think this information should also be easy to find for everybody on your website in the first place.
1 of 1 people found this helpful
There is no one guide or one size fits all but a couple best practices...
Use a mandatory profile in XA/RDSH, local profile on anything else.
AppSense agents can go into an App Layer
Before shutting down for finalize, run ccacmd /imageprep (details in the guides)
If using PVS/MCS run the same ccacmd /imageprep before sealing your image.
Make sure you apply your hook excludes: Recommended AppSense Exclusions for Citrix Hooks
After installing the agents make sure the installation schedule for your agents in your deployment group is set to disabled
Check the box to "Download configs at startup" is checked for any deployment group containing non-persistent machines
I know I'm missing some things but just a quick brain dump. Let me know if you guys have any questions.
Hi Landon, thanks for your brain dump! It is a very nice start, but as I stated earlier, I miss some official KB article or something regarding the combination of DesktopNow en Citrix. It's now a bit scattered or you need to find it in replies within the discussions. As a Citrix Ready product, I would expect a bit more.
Wow! This is very useful! Many thanks. The only thing I am missing in this document, is the specific use case of non-persistent desktops (Citrix XenDesktop/VMware Horizon, etc.). There are specific best practices for this use case like mentioned earlier:
- Use a mandatory profile in XA/RDSH, local profile on anything else. --> where to find a recent procedure? Is it also possible to use a local profile?
- AppSense agents can go into an App Layer.
- Before shutting down for finalize, run ccacmd /imageprep (details in the guides) --> What does the ccacmd process exactly do? I can find some documents regarding this tool, but I can see that it also removes several registry keys and this is not mentioned anywhere.
- If using PVS/MCS run the same ccacmd /imageprep before sealing your image.
- Make sure you apply your hook excludes: Recommended AppSense Exclusions for Citrix Hooks
- After installing the agents make sure the installation schedule for your agents in your deployment group is set to disabled.
- Check the box to "Download configs at startup" is checked for any deployment group containing non-persistent machines.
- Do we have to redirect the AppSenseVirtual folder used by Personalization Server to write file and Registry changes locally (%systemdrive%\appsensevirtual), e.g. to D:\?
These recommendations (including some clarification, see above) should be included in this guide. Again, many thanks for the guide in its current state!
- Configuring mandatory profiles: BP06 - Configuring Mandatory Profiles
- /imageprep removes the two GUIDs in the registry to generalize the CCA
- You do not need to redirect AppSenseVirtual as its just a temporary location used by personalization.
Hi Landon, thanks for the answers. Very useful, except for the mandatory profile. This procedure is totally outdated and no longer valid for a more recent OS like Windows Server 2012(R2)/2016 and Windows 8/10. The only supported way of creating mandatory profiles for these operating systems is described in Create mandatory user profiles (Windows 10) | Microsoft Docs and additionally in Create and deploy a Windows 10 roaming mandatory profile – 4sysops and How to create mandatory profiles in Windows 10 Creators Update (1703) - HTG | Howell Technology Group (even updated for version 1703). It has become quite a lengthy and complicated procedure. This procedure is also described in a Ivanti (!!) presentation, see UEMB300: Windows Profiles 101, starting from slide 23. It's because of this complexity that I wondered whether a local (default) profile would also work and what pitfalls we should know in this case when combined with Ivanti (EM and Personalization Server)?
However, I guess the use of the procedure above is for your own risk, as the one described by Microsoft in Create mandatory user profiles (Windows 10) | Microsoft Docs is the only officially supported method.
The MSFT article is just a how to much like the AppSense doc is a how to. There is nothing stating that is the only way to create a profile. In the end a profile is just a bunch of files and folders with a registry file as well. Here is a blog post that talks about the two methods:
The blog post fails to mention that EM out of the box captures active setup and the items it customizes so the logon hit is only the first logon much like on a physical workstation or if using a roaming profile. This is ideal as active setup and other items like StartMenuInit and UserSignedIn customize the user profile for the currently logged in user. Once they run EM captures those customizations. If you go the MSFT route you would already have the customizations made in the profile but for the wrong user. Things like the windows libraries break for example.
There was a good 2011 BriForum session that LONG time AppSense employee Jon Wallace presented on mandatory profile tuning but the video link seems to be missing now. It takes the AppSense method to the next level.
From the second link:
Jon does the following to tune a profile:
- Create a copy of a clean/untouched default user profile
- Login as any user and tune the user environment to how you want it
- Export registry settings from the logged in user into hive files (.hiv)
- Import registry settings into the copy of the clean default profile
This method creates a default/mandatory profile that’s smaller and cleaner than the other methods of creating them (ie: sysprep method supported by Microsoft, or copying the configured user profile and eliminating junk).
The profiles created using this method are lean and fast but are prone to user mistakes as you export and import keys and settings and are also not automatically documented. I like to use a clean default and use EM policy actions to customize the profile if needed as its self documenting in the config.
In the end its up to you which way you go but the AppSense method has worked great for hundreds of my customers over the years.