Archive
Feed of Windows Azure Pack Gallery Resources and SCVMM Service Templates is now LIVE
The feed of Windows Azure Pack Gallery Resources and SCVMM Service Templates is now LIVE at:
http://www.microsoft.com/web/webpi/partners/servicemodels.xml
The initial set of service models are:
- Gallery Resources
- o Windows Server 2012
- o Windows Server 2012 R2
- o Windows Server 2012 WebServer (IIS)
- SCVMM Service Templates
- o Sharepoint 2013
- o Service Template Example Kit
You can enable this feed and download your first service model in just a few easy steps (and the first 2 steps are one-time overhead).
- Install the Microsoft Web Platform Installer from here: http://www.microsoft.com/web/downloads/platform.aspx
- Add the Service Model Feed as a custom feed
- Launch the Web Platform Installer
- Select the Options link at the bottom right, next to the Install button
- Enter the Feed URL into the Custom Feeds field http://www.microsoft.com/web/webpi/partners/servicemodels.xml
- Select the Add feed button
- Select the OK button
- You will now see a new Service Modelslink at the upper right of the Web Platform Installer UI
- Select the Service Model you want to download
- Select the Service Models link at the top of the Web Platform Installer UI
- Select the Add button next to whichever Service Model you would like to download
- Select the Installbutton
- Accept the usage terms
- Select the I Accept button
- Select the Continue button
- Select the Finish button
- A Windows Explorer window will open, displaying the contents of the Service Model. Service Models are extracted into your %SystemDrive% folder, according to type
- Gallery Resources – %SystemDrive%GalleryResources<resourcename>
- SCVMM Service Templates – %SystemDriveSCVMM Service Templates<resourcename>
- Follow the directions in the Service Model readme to load the model and prepare any dependent resources (VHDs, etc) for deployment.
App-V: On that Failed Office Add-in
Troubleshooting virtualized Office add-ins are always fun. Correction: troubleshooting Office add-ins are always fun for people like me – not necessarily normal human beings. Whether you are using add-ins with a local instance of Office or are packaging add-ins with virtualized Office, you need to be to understand how Office knows which add-ins to load and how these will be loaded.
There are generally three ways to virtualize add-ins for Office:
1.) Where Office is installed locally and the Add-in is virtualized – The Office application must have a shortcut/OSD file provisioned in order to be brought into the virtual environment. Starting with App-V 4.6 SP2, the App-V Sequencer has a specific workflow that allows for this.
Be advised that when you do this, you will be bringing in the local instance of Office into the virtual environment in order to load the add-in. What this can lead to is other add-ins which may not be virtualized not loading if the configuration is not set properly for this. Having a clear understanding of your Office add-in ecosystem will help in developing a strategy in advance to avoid this.
2.) Through Connection Groups or Dynamic Suite Composition (Depending on the Version) – You can also take advantage of both the Add-in/Plug-in workflow and the “Expand Package to Local Disk” feature of the sequencer in order to package Office and Add-in applications separately but still connect them into a common virtual environment.
This method works best (in my opinion) when your strategy is to virtualize both Office and the add-ins. This is also the only way I use Add-ins with Office 2013.
3.) Office and add-ins packaged together into one package (often sequenced using a single pass.) This way is the least common and not always recommended as it may require you to deploy multiple Office packages.
Verify the Add-in Registry Keys
When an add-in is installed, it can be registered to either the user or to the whole machine. When an add-in is sequenced, it will also be virtualized and depending on the registry opacity configuration, will override whatever is locally present. User-registered add-ins go to HKEY_CURRENT_USER while add-ins registered to the entire machine go to HKEY_LOCAL_MACHINE. Whether Office is local and being brought into the virtual environment or Office is virtualized with the Add-in, Office needs to be able to understand the “Load Behavior” of the add-in. This will be found under
HKEY_LOCAL_MACHINESoftwareMicrosoftOffice<APPLICATION>Addins
Each Add-in appears as a subkey beneath this key. The LoadBehavior DWORD value determines how it will load. This key is the #1 culprit when it comes to Add-ins not working right whether it is a “1st launch-only” issue or an “always-launch” issue. It is a DWORD value. By default, this entry is set to 3, which specifies that the add-in is loaded at startup but an many cases, especially if the add-in was launched during sequencing, you may run into a situation where the value may be set to something else depending on what was done during sequencing. If the value is 0, then the add-in will have to be enabled once the user launches the application. If the package is repaired it will have to be enabled again. The value 1 can be misleading and I encounter this a lot in virtual add-in troubleshooting. Add-ins dialog box indicates that the add-in is loaded after the application starts, the add-in isn’t actually loaded. If the application successfully loads the add-in, the LoadBehavior value changes to 0, and remains at 0 after the application closes. The value 2 means If the application successfully loads the add-in, the LoadBehavior value changes to 3, and remains at 3 after the application closes. With App-V this means potential issues in prompts including annoying “success messages.”
LoadBehavior at 3 is good for App-V
Hey, I made a rhyme! If the LoadBehavior value is set to 3, it will always try to load the add-in and if the add-in fails, will set it back to 2. This is what we want in the virtual registry of our App-V package most of the time. You can usually verify/set this in the Virtual Registry tab after sequencing prior to saving the package.
Should I Verify Registry Opacity?
Yes. While you are there you may want to verify your registry opacity settings. Are those Add-in keys set to “override” or “merge” with the local key. If you have local add-ins that you will use alongside of these virtual add-ins, you will want to ensure that the Addin key is set to merge.
What about Outlook Add-Ins?
For Outlook, you will most assuredly need to manually import/add these virtual registry entries during sequencing (or package upgrade) since you do not want to be launching Outlook during sequencing.
Check the Event Logs when Troubleshooting
While the event logs may not have the event handlers registered for office (since it is virtual, you will still see unregistered event ID’s of Outlook (Event ID 45) which will list all of the add-ins loaded and their subsequent load times.
Event ID: 45
Outlook loaded the following add-in(s)
Office 2013 and Mismatched Virtual Subsystem Settings
If you are using Virtual Office 2013 with App-V 5, this is the #1 issue. Given all of the changes with Office 2013 virtualization, one would think the Add-in story would become complicated. It is not. The recommended practices are pretty straight-forward:
On the Sequencing Machine:
1.) Install the App-V 5 Sequencer.
2.) Install Office 2013.
3.) Start a new package.
4.) On the “Type of Application” page, select “Add-on or Plug-in.”
5.) Select the installer for the plugin.
6.) In the “Install Primary” page, select “I have installed the primary parent program” and continue.
7.) Install the plugin and save the package.
8.) Depending on the add-in, you may need to run it during sequencing.
Client Configuration
1.) Copy your Office 2013 to the client machine
2.) Copy the sequenced add-in to the client machine
3.) Modify the add-in’s DeploymentConfig.xml file and modify the following:
4.) Search for:
“<COM Mode=”Isolated”>”
modify to
“<COM Mode=”Integrated”>”
5.) Search for:
“<Objects Enabled=”true” />”
modify to
“<Objects Enabled=”false” />”
The Connection Group will fail if the above changes are not made.
6.) Build a Connection Group document for both Office 2013 and the Add-In. You can do this with stand-alone testing by using the following resource on creating a Connection Group XML document: http://technet.microsoft.com/en-us/library/jj713474.aspx
7.) Enable Package Scripts
Set-AppvClientConfiguration -EnablePackageScripts 1
8.) Add the Office 2013 package; publish it Globally
Add-AppvClientPackage –path <path_to_office_package_>.APPV | Publish-AppvClientPackage –Global
9.) Add the Add-In package; publish it Global
Add-AppvClientPackage –path <path_to_office_addin>.APPV | Publish-AppvClientPackage –Global
10.) Add the Connection Group pointing to the Connection Group document you created earlier. Enable it Globally
Add-AppvClientConnectionGroup –path <PATH_TO_CG_DOC>.xml |Enable-AppvClientConnectionGroup –Global
11.) Launch the Office application the add-in uses.
My Own App-V 5 Heart of Darkness
Today I became an idiot. Fortunately, it did not last long . . .
So I am refining and tuning my test Shared Content Store configuration in search of finding every possible way of tuning and optimizing its performance, and I found myself inside my own Joseph Conrad novel. To say that I was figuratively beating myself in the head with a hammer would be an understatement.
So as I move my client back and forth between one SCS store vs. another, I found my client behaving like it was completely dead – unable to launch ANY application – even after disengaging SCS mode altogether (and trying with a simple local package only to find that I could no longer add any packages.) Every package add failed with error 8007007b.
For some reason, instead of looking up the error code, I assume I had just corrupted my machine. So I reverted my snapshots and went in and added my PackageSourceRoot and PackageInstallationRoot overrides and found myself again getting those errors. Looking at the error code this time, I find the HRESULT is a standard I/O error of an invalid name (STIERR_INVALID_DEVICE_NAME or ERROR_INVALID_NAME)
It quickly dawned on me that I reverted to Unix-style path conventions (Hey, it works in Explorer and CMD) and the App-V client does not like that syntax (i.e. //server/share.)
A quick correction and all was well again. Lesson learned. Do not use forward slashes for paths when configuring the PackagInstallationRoot override.
By the way, if you are looking for an equivalent to the ApplicationSourceRoot configuration from 4.6, use the PackageSourceRoot override. Bear in mind that this is only used when the clients needs to create a new streaming session (mount) for a package that has not already been “cached” or streamed. If this is changed, the effect won’t be seen right away on packages that have already done streaming operations since the last client restart, unless 30 minutes have passed since the last bits were streamed. That is the idle timeout for an App-V 5 “Streaming Session.” You can also opt out of this override for any particular package using the <ProductSourceURLOptOut> option in the Deployment_Config.xml file.
Incidentally, I would recommended this post as a starting point for understanding the Shared Content Store: http://blogs.technet.com/b/virtualvibes/archive/2012/10/24/introducing-shared-content-store-in-app-v-5-0-goodbye-shared-read-only-cache.aspx
I’ll be publishing some optimization recommendations as well soon – so long as I don’t get further bogged down by my own stupid mistakes.
madvirtualizer
The Mad Virtualizer at Microsoft 