Archive

Archive for June, 2013

MED-V V1: How to Update the Policy Update\Polling Interval


Within MED-V V1, you can modify the default policy interval by modifying one of the XML files on the client. While the official documentation alludes to this:

“A typical MED-V Management Server can support 5000 users based on the recommended hardware configuration. The client-server communication is lightweight: clients are normally configured to poll the server for policy every 15 minutes, and image updates every 4 hours (Can be changed using MED-V configuration)”

What is does not state is how exactly you change the policy update interval from the default interval of 15 minutes.

To modify the Policy Update Interval, this would have to be done on the client side. You can do this by editing the Configuration.XML located in %ALLUSERSPROFILE%\MED-V\Local\Config

The value is UpdaterTimeInterval and it is found under the element as displayed in the example below:

<Configuration>
<SpecialFileProcessor>
<WorkspaceKeys type="System.String">Kidaro.KeysStorage.KeysConfigurationFileProcessor</WorkspaceKeys>
<ClientPolicy type="System.String">Kidaro.Policy.Server.PolicyFileProcessor</ClientPolicy>
</SpecialFileProcessor>
<!-- Should the service update the configuration from the server. -->
<EnableServer type="System.Boolean">true</EnableServer>
<!-- Time interval in seconds between updates of configuration files. -->
<UpdaterTimeInterval type="System.Int32">900</UpdaterTimeInterval>
</Configuration>

Increase the default UpdaterTimeInterval value of 900 (15 minutes in seconds) to desired interval then save the file and restart the MED-V Client service.

App-V 4.6: Troubleshooting A09 Errors (04-00000A09) with Office Deployment Kit Proxies


One touchy feature that has frustrated packagers has been the issues arising when the ODK (Office Deployment Kit) proxies are not configured properly. When this happens, search will not properly work, MAPI configuration will not work properly, and even headaches with “Mail” Control Panel. The erro displayed is very quick and very terse.

The Application Virtualization Client could not launch the application you requested.

The specified application does not exist. Check the name you specified, and then try again.

Error code: xxxxxxx-xxxxxx04-00000A09

The error is pretty straight-forward. The App-V client went to launch an application using the SFTTRAY command, and it does not match anything published on the client – but you know it’s there, right? You checked. The OSD matches. Even launching the OSD manually with the SFTTRAY works. So what in the heck is going on?

4.6 Proxies – Trail of Consistency

 

 

 

By design, what you specify during the deployment of the ODK (Office Deployment Kit) is extremely important in the automation and integration of these proxies, or virtualization handlers as they are more appropriately called. When you are sequencing Office 2010 and deploying via App-V, you have to also deploy the virtualization handlers using the Office Deployment Kit. As you can see from the diagram above, the command to call the virtual application (in this case – the mail search) will be constructed based upon two options specified when deploying the Office Deployment Kit – PACKAGEVERSION and the name of the Proxy (i.e. MAPIPROXY, MLCFG32CPL, etc.) In the case of the mail search, it is VIRTUALSEARCHHOST. This information is mentioned deep inside the Prescriptive Guidance document, but is often overlooked. What is not mentioned is that these will be registered locally in the following key: HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CVH

In the case of the Virtual Search Host, a subkey called Click2runWDSProxy should exist with an entry for the Package GUID in {GUID} format followed by the SFTTRAY command to launch the application.

So let’s say you install the Office Deployment Kit using the following parameters:

ADDDEFAULT=Click2runMapi,Click2runWDSProxy,Click2runWDS,Click2runOutlookProxies,OSpp,OSpp_Core,Click2runOWSSuppProxies PROPLUS=1 OUTLOOK=1 KMSSERVICENAME=booger.contoso.com OUTLOOKNAME=”Microsoft Outlook 2010″ PACKAGEVERSION=”14.0.6025.1000″ PACKAGEGUID=”{GUID}” MAPISERVER=”Microsoft Virtual Office Simple Mapi Proxy Server” VIRTUALSEARCHHOST=”Search MAPI Protocol Handler Host” MLCFG32CPL=”Mail” OWSSUPPServer=”Microsoft SharePoint Client Support Manager” 

The Office Deployment Kit will have the expectation that the following will be configured during sequencing:

Option

Application Name

OSD File

MAPISERVER

Microsoft Virtual Office Simple Mapi Proxy Server 14.0.6025.1000

Microsoft Virtual Office Simple Mapi Proxy Server 14.0.6025.1000.osd

VIRTUALSEARCHHOST

Search MAPI Protocol Handler Host 14.0.6025.1000

Search MAPI Protocol Handler Host 14.0.6025.1000.osd

OWSSUPPServer

Microsoft SharePoint Client Support Manager 14.0.6025.1000

Microsoft SharePoint Client Support Manager 14.0.6025.1000.osd

MLCFG32CPL

Mail 14.0.6025.1000

Mail 14.0.6025.1000.osd

 

If you leave out the PACKAGEVERSION option, that’s bad. That will add an additional trailing space to the constructed SFTTRAY command. Even if you include the version in the name, leaving out the PACKAGEVERSION option still causes this. This means you will need to make sure all of the versions specified in the application names (created during sequencing) are identical so the right virtual application will then be launched and you can avoid those A09 errors.

 

Categories: Uncategorized Tags: , , , , ,

Microsoft Virtual Academy – Private & Hybrid Cloud Events


Join Microsoft MVP Pete Zerger for a free two-day Jump Start series covering the end-to-end process of implementing a Microsoft cloud solution.

Registration is free for both days: Sign-up now.

Day 1: Building Private Cloud with Windows Server 2012 & System Center 2012 SP1

This June 18 Jump Start will be a scenario-based, bottoms-up approach to designing and building our private cloud on Windows Server 2012 and incorporating the full spectrum of System Center 2012 SP1 components.

MVP Pete Zerger and Microsoft Sr. Technical Evangelist Symon Perriman will focus on bringing a greater understanding to key topics related to the fabric – such as virtual networking, leveraging the storage and networking capabilities of WS2012, and creating service templates in VMM and on the Service Manager CMDB as we move up the management stack. Additionally, you will learn how the service-catalog comes together to deliver an intuitive self-service experience in a step-by-step approach that will address many common questions.

Day 2: Moving from Private to Hybrid Cloud with System Center 2012 and Windows Azure IaaS

This June 20 Jump Start is a continuation of Day 1 and will focus on successfully monitoring and managing ongoing operation of a private cloud environment.

MVP Pete Zerger and Technical Product Manager Matt McSpirit will provide examples of how to integrate Windows Azure IaaS into our private cloud to deliver hybrid cloud capabilities in System Center 2012 SP1, explain how to develop hybrid cloud self-service scenarios in System Center 2012 App Controller and in the System Center Service Manager Self-Service Portal, and demonstrate full integration of private and public cloud with ITIL.

Register for Day 1.

Register for Day 2.

App-V 5.0: On these 0xc0000142 errors and where they are coming from.

June 10, 2013 8 comments

“Where are these 0xc0000142 errors coming from in App-V 5.0?”

There has been some chatter revolving around this generic application error that is happening with many LOB (Line of Business applications) running virtualized with App-V 5.0. You will also note that for a lot of these applications, this issue did not occur in previous versions of App-V. The error is as follows:

The application was unable to start correctly (0xc0000142). Click OK to close the application.

First of all, this is not an App-V error but rather a generic application error. Does this mean that App-V did not play some role in it? No. Obviously that would not be the case if the application behaved fine prior to virtualization. So in order to isolate what App-V’s role is, we need to understand first what the error means.

This error (0xc0000142) technically resolves to STATUS_DLL_INIT_FAILED in the native API – which simply means that it was unable to load or initialize a critical DLL, etc. If there is a DLL mismatch or some other type of subsystem failure, you will get this error. If the DLL can be found and loads but fails to initialize, you will also get this error.

I know of one type of application where you may find this most prevalent. In one specific type of use case, there may be applications that are written with client-side “bootstrap” executables. These executables then load server-side modules over the network. These applications were written to allow for ease of updating on the back end. In App-V 4.x, when these applications loaded these modules, they would be impersonated on behalf of the user so the user just needed to have read and execute permissions to access these modules over the network. Even under App-V 4.x, these modules would be brought into the bubble under the context of the current user account.

In App-V 5.0, the App-V Client is running as system, which means file operations will operate under the AppVClient.exe process which will be running under the context of the local system account and not the user account. Even though the executable is loaded into the context of the user running the program, the file operation will be spearheaded by the AppVClient.exe process and the access will not be impersonated. So in the case of these 0xc0000142 errors, it is likely because there is a file operation that is occurring under the system account. It will fail authentication, thus preventing the loading of the DLL causing this error.

How do I know if this is the case?

Once again Process Monitor will be your friend. It will involve a very simple procedure to isolate this. First reproduce the issue while capturing the events with Process Monitor. Once you have done that all you need to do is apply a quick filter to see if, in fact, the AppVClient.exe is getting a logon error when trying to access the share where the DLLs are located. The events you need to filter for are:

  • Process Name: AppVClient.exe
  • Operation: Create File
  • Result: LOGON FAILURE

 So what do I do now?

You can resolve these errors by granting access (RX) to the directory for the computers accessing the shares as SYSTEM. Bear in mind they will need that at both the share level and the NTFS level. As of now, that appears to be the best point of remediation.

Categories: Uncategorized Tags: , , ,