Daniele Tosatto

It’s easy to run a local installed application isolated. WhyI should run applications isolated and last but not leased what is the impact of running a local application isolated?
Let’s start with an application Citrix is using that way: Internet Explorer. When Application Streaming is used to run an Internet Explorer Add-on, it does exactly what I want to do: Running a local installed Internet Explorer isolated to make the add-on available for the user.
So the question is now, are there other applications where you want to run an add-on isolated/streamed. Yes there are! The first time I run into that question, was the day I isolated 7-Zip. It is an easy task to profile 7-Zip, but because Explorer is not “aware” of the streamed “zip utility” the explorer context menu does not contain the 7-Zip Add-on.

But if you run Explorer isolated the context menu contains the 7-Zip extensions. Now there is the question. How can I run Explorer inside an isolation environment of a streamed application?
Simply by “calling” Explorer or any other installed executable from inside the isolation. There are many ways to do so: I like to do everything possible inside the Citrix Profiler, so I created a run_Explorer.cmd file, but you can also define a start script starting explorer (with option /e,). The cmd script I added to the target and also defined it as an application shortcut.
Now 7-Zip is shown in the context menu of Explorer.

As a side effect now the 7-Zip installation files are “visible” to Explorer. If you need details on how to do it step by step look here: Blog from Joseph Nord: AIE on Desktop and AIE via App Streaming

Now it looks like everything is done. Isn’t it? No it is not. Running Explorer locally has a lot more impact: When using Explorer you change settings, you create files, copy files and all this tasks are running isolated, controlled by the Isolation rules.
So the last thing you have to do is consider in which way the isolation rules impacts the application behavior and how to change them.

The following registry changes are recommended for all deployment scenarios and would almost always be desirable in a Windows 7 hosted VM-based VDI desktop implementation:

Note: The Optimizer column indicates whether this registry change is included in the XenConvert Optimizer tool that is installed with the Provisioning Services target device software.

Standard Mode Recommended Configurations

The next set of registry changes are recommended for images deployed using standard mode vDisk images with Citrix Provisioning services. Standard mode images are unique in that they are restored to the original state at each reboot, deleting any newly written or modified data. In this scenario, certain processes are no longer efficient. These configurations may also apply when deploying persistent images and in many cases should be implemented in addition to the changes recommended in the preceding section.

Optional Configurations

This last set of machine-based registry changes is optional regardless of whether the image is deployed as a persistent or standard image. In many cases, the following configurations should be implemented; however, these configurations should be analyzed for suitability to each unique environment.

Note: These are only recommendations. You should implement these at your own risk

Remember, you can stay current with this and other Windows 7 virtual desktop recommendations via the Virtualize My Desktop – Windows 7 site.

Administration has changed quite a bit in XenApp 6. Not only have a few Citrix-related policies have been added or modified, but there are new options for administration. Citrix policies are now based on user or computer policies, and they can be administered as Active Directory GPOs. That combined with Worker Groups based on OUs may initially seem complex but really can mean much more efficient administration of your XenApp servers via Active Directory—if you understand your options.

First, let’s take a look at the options that are available for administration of Citrix computer policies based on the Citrix recommended preference order:

Worker Groups can be based on OUs, Server Group Accounts, or Farm Servers. Essentially, it is a grouping of servers that will take on the same characteristics, and each server can belong to one or more worker groups. If OUs are used as the basis for Worker Groups, servers that are added or deleted from OUs automatically take on the characteristics of a specific Worker Group. Please see CTX124481 for more information about Worker Groups.

Where possible, Citrix recommends administering XenApp 6 via Active Directory using the Group Policy Management Console; it is installed by default with XenApp 6 for this purpose. However, the administrator must have administrative rights to the OUs that house the Citrix servers. Please see XenApp 6 Policies and Group Policy Integration for more information about XenApp 6 policies.

To take it one step further, when Citrix Provisioning services is used to create new XenApp servers, these can automatically be assigned to an OU. If published applications and Citrix policies are configured based on Worker Groups and Worker Groups are based on OUs, administration is greatly simplified. Let’s walk through that flow:
• New server gets provisioned via Citrix Provisioning services; it is automatically assigned to an OU
• The server automatically inherits characteristics based on the Worker Group designation, including published applications and Citrix policies

Thus, the only process initiated was the provisioning of the new XenApp server. If the applications are embedded in the XenApp image or automatically streamed, the server is now functional.

Additionally, an administrator should:
• Apply the correct load evaluator (newly installed server defaults to the default load evaluator)
• Move the server to a different zone if required
That’s it!

Citrix does not recommend mixing administration methods. A mix-and-match approach can cause undesired results because the policies are applied from different sources and may overwrite in ways not intentioned. It’s kind of like three business partners having access to a bank account and no one looks at the balance before making a withdrawal—the results may not be good.

As an example, if you import policies via the XenApp 6 Migration Tool, those policies are written into the IMA Data Store. If you plan to administer your new XenApp 6 farm by means of Active Directory, you’d have policies in two repositories, i.e., AD GPO and IMA Data Store. Keeping in mind that Citrix policies are applied based on hierarchy – i.e., the precedence order is child OU; parent OU; subsequent parent OU; Domain; Site; IMA; Local – having policies in more than one place may produce results other than what you had intentioned. If you want to streamline the imported Migration Tool policies into an AD GPO, additional steps are required. Look for an upcoming blog from Juliano Maldaner that explains this.

XenApp 6 provides multiple options for administration. If unsure as to which is best and you have administrative rights to Active Directory for OUs that house the XenApp servers, use the Group Policy Management Console. Nonetheless, make a decision initially as to how you will administer your XenApp farm and then continue to use that method.

Citrix Support have been developing tools to help troubleshooting your Citrix environments for many years now. Below you will find the full list of tools available from Citrix Support along with links to useful resources.

When you use the Refresh Server option to refresh a Publishing Server from the Microsoft Application Virtualization (App-V) Client MMC snap-in, you may receive the following error message:

The Application Virtualization Client could not update publishing information from the serverServerName.
No connection could be made because the target machine actively refused it.
Error code: xxxxxxx-xxxxxx2A-0000274D

This issue can occur if the App-V client cannot communicate with the Publishing Server.

For all the latest information including how to troubleshoot and resolve this issue see the following Knowledge Base article:

KB2266481 – Using the Refresh Server option to refresh a Publishing Server from the Microsoft Application Virtualization Client MMC snap-in results in error code 2A-0000274D

Have you ever had a need to generate a large number of user accounts within Active Directory and didn’t have the time to manually create them?

Active Directory User Creation Utility will solve your problem!

Launch and configure the utility
Double-click the CreateADUsers.exe file from the downloaded ZIP file to launch the utility. This application can be run from any domain member, it doesn’t have to be run on the Domain Controller. I believe the only requirements for use are that you should log onto your machine as a domain user that has rights to create objects within Active Directory. Your machine should also have the .NET Framework 3.5 installed.

If you have ever manually created user accounts within the Active Directory Users and Computers snap-in, the utility should be pretty self-explanatory. Just in case, the instructions for how to configure the utilty are provided below:

Run the utility
When you click the Create Users button, the utility will attempt to create the requested number of accounts in the specified OU within Active Directory. If you requested a large number of accounts, it may take a few minutes. A message box will be displayed with the status of the request. An event log entry is also created with additional details and is recommended to check if you run into any issues.

If you specified random passwords for the accounts, you will definitely need to check out the Accounts.txt file that is generated so you can get the passwords for those accounts. You should record these passwords in the proper location and delete this file for security purposes 

Verify the Active Directory accounts have been created
Finally, open the Active Directory Users and Computers snap-in and verify the accounts were created in the proper OU. Feel free to modify the accounts further with profile information or other details. The accounts will be easily visible since the text Auto-generated account will be shown in the description field.

Key source code
Many of you may want to just incorporate this functionality into an existing application that you are building. I provided the full source code as a separate download at the bottom of this article. It’s a Visual Studio 2008 project.

Download the utility and full source code
The utility and full source code are provided below:

• Download the Active Directory User Creation Utility (EXE)
• Download the full source code

hen you use the Refresh Server option to refresh a Publishing Server from the Microsoft Application Virtualization (App-V) Client MMC snap-in, you may receive the following error message:

The Application Virtualization Client could not update publishing information from the server server name.
The server could not authorize you to access the requested data. Please report the following error code to your System Administrator.
Error Code: xxxxxxx-xxxxxx04-00000917

This issue can occur if the user is not a member of a user group that is specified under Group Assignment in the Provider Policy on the App-V Management Server.

To resolve this issue, verify that you are a member of a user group that is associated with the provider policy. To do this, follow these steps:

1. On the App-V Management Server, click Start, Administrative Tools, and then click Application Virtualization Management Console.
2. In the navigation pane, expand the server name object, and then click Provider Policies.
3. In the details pane, double-click the required policy. For example, double-click Default Provider.
4. Click the Group Assignment tab.
5. Verify that you are a member of one of the user groups that is listed or add a user group that’s missing.

For the latest version of this information please see the following Knowledge Base article:

KB2266600 – Using the Refresh Server option to refresh a Publishing Server from the Microsoft Application Virtualization Client MMC snap-in results in error code 04-00000917

An application on a Microsoft Application Virtualization (App-V) client may fail to launch with the following error:

The Application Virtualization Client could not launch application name.
The specified Application Virtualization Server could not be accessed.
Try again in a few minutes. If the problem persists, report the following error code to your System Administrator.

Error Code: xxxxxxx-xxxxxx0A-10000002

This issue can occur if the App-V server name specified in the HREF attribute in the application .osd file is using the %SFT_SOFTGRIDSERVER% environment variable but the environment variable is not configured on the App-V client.

For the most current information including the resolution, please see the following Knowledge Base article:

KB2271342 – An application on an App-V client fails to launch with Error Code: 0A-10000002

Citrix Support published Top 10 Technical articles for June 2010.

Find below the Citrix Knowledge Center Top 10.

Top 10 Technical Articles

Top 10 Whitepapers

Top 10 Hotfixes

Top 10 Presentations

Top 10 Tools

Steve Bucci, Microsoft Support Escalation Engineer , recently posted another great video he put together that shows you how to troubleshoot and correct some common configuration mistakes by guiding you through the areas to double-check in a typical App-V deployment.  Whether you’re new to Microsoft Application Virtualization or a seasoned veteran, you’ll definitely want to spend the 10 minutes to check out this short video:

For more information on troubleshooting some common App-V issues see this post by Microsoft App-V Support Escalation Engineer Steve Thomas.