Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Recent Posts

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

MSI, MST, and disabling auto-healing/ self-repair/ “please wait while Windows configures” messages for certain applications

This issue had be irritated for a week. Finally, thanks to this blog post I think I solved it. Fingers crossed. Bloody Darwin descriptors! :)

So what was the issue? I setup Citrix XenApp for Office 2010, FileSite, and some more applications. The first time I’d launch Outlook 2010 and go to FileSite it would do this initial configuring:

Fair enough – I figure it has to do some initial registry key and folder stuff. I can live with that.This initial configuring is not too harmful either except for a bit of delay to the user. Via GPOs I have pushed out registry keys to set my default library and also tweak some FileSite settings, and this initial configuring does not blow away any of that.

Next I launch Word or Excel and they work happily with no initial configuring. However, sometimes – and this seems to be either when I launch Word or Excel soon after I click Outlook, or when I open one of these via Outlook (like I double click on an attachment), or sometimes just randomly – Word and Excel too do this initial configuring. And they blow up all my GPO pushed out registry settings and that irritates the hell out of me!

Something was causing these two to randomly trigger a repair of FileSite and I had no idea what. I figure it must be some registry key or file that is missing and that’s causing Word or Excel to repair FileSite, but I couldn’t find anything. I spent some time with Citrix UPM doing trial and error, checking to see if I was excluding some important folder, but couldn’t find anything. (I know should have just used SysInternals Procmon to find out what was triggering this I guess, but I felt lazy going that route). Then I decided to try and explore the MSI/ MST file itself and see what I can learn.

I used Orca to view the MSI file and apply the MST transforms to see what was happening. Truth be told, while it was good to understand the structure and what one can do, it didn’t really get me anywhere. From the Application logs on my machine I could see messages like these:

And using Orca I was able to track down these features and components and see what files or registry keys they might be looking for. My hunch was that possibly the file or registry key looked for by these components were missing and that was triggering a self-repair for FileSite. But all those keys and files were present on my machine as far as I could tell, so that was a dead-end.

Here’s an amazing article on features and components and how the self-repair feature is triggered when a file it requires is missing. And here’s another amazing post from StackOverflow that generally goes into the topic of self-repair.

Every time you launch an advertised shortcut (essentially a special shortcut that points to a Windows Installer feature and not directly to a file), Windows Installer will verify the installation by checking the “component key paths” for your product. If a discrepancy is found, a repair is triggered to correct the incomplete installation. The “component key paths” are the “key files” specified for the components inside your MSI – there is one per component. Self-repair can also be initiated by someone instantiating a COM server (or attempting to), someone activating a file via its file extension or MIME registration, and a few other ways.

The impression I got from both articles is that there are entry points to an application and it is possible to tell Windows to do an integrity check when accessing the application via these entry points and if the check fails then do a self-repair. I am not sure if the “Please wait while Windows configures …” window is part of the integrity check or self-repair, but considering it was making changes I am sure it was triggering the self-repair anyways. There are a lot of entry points, from the advertised shortcuts mentioned above (see this article for an example) to activating a repair when doing an action such as opening a document or print.

(As an aside, an MSI/ MST has an ALLUSERS property that determines if it is installed per-machine or per-user or both).

While reading on this topic I also came across this informative article on COM and registry stuff. It isn’t directly relevant to self-repair but has an indirect reference. Here’s some bullet points (note: the actual article has a lot more stuff):

  • COM objects (DLLs? also object classes?) are identified by a GUID. This is called a Class Identifier (ClassID). These are stored under HKEY_CLASSES_ROOT\CLSID. In my machine for instance C:\Windows\system32\oleaut32.dll has a ClassID of {0000002F-0000-0000-C000-000000000046} and can be found under HKEY_CLASSES_ROOT\CLSID\{0000002F-0000-0000-C000-000000000046}.
  • Within the CLSID key in the registry there exists a key called InprocServer32 that points to the actual DLL referenced by the ClassID.
  • Since ClassIDs are GUIDs and hence difficult to remember, we also have Programmatic Identifiers (ProgIDs) that are pointers to these. (It’s like DNS basically. The ProgID is the DNS name; ClassID is the IP address). ProgIDs are stored under HKEY_CLASSES_ROOT.

To take an example from my machine: HKEY_CLASSES_ROOT\Citrix.ICAClient is the ProgID for the Citrix ICA client. Within this HKEY_CLASSES_ROOT\Citrix.ICAClient\CLSID gives me its ClassID which is {238F6F83-B8B4-11CF-8771-00A024541EE3}. I can find this ClassID under HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{238F6F83-B8B4-11CF-8771-00A024541EE3} (notice it can also be under Wow6432Node coz my machine is 64-bit).  In this HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{238F6F83-B8B4-11CF-8771-00A024541EE3}\InprocServer32 points to C:\Program Files (x86)\Citrix\ICA Client\wfica.ocx.

Elsewhere in my machine I also have HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/x-ica which has a CLSID value pointing to the above. So this is how MIME types are associated with the OCX file above (whatever that does).

The above article is the first time I came across the Darwin Descriptor. It was briefly mentioned as something that could be in the InprocServer32; but more on that soon.

Searching more on these topics and self-repair I came across this article. I think I was searching for entry points that trigger self-repair and by now had an idea that self-repair could probably be associated with the registry keys I mentioned above. I’d like to excerpt this FAQ from the same article (emphasis mine):

Q1: Who decides what components are “required”, and what is “intact”?
A1: The author of the installation package. Quite often, he simply follows the wizard in his MSI-authoring product without giving full consideration to what is really required, what is not, what should stay intact and what should not. “Intact” means that the specified file or registry key does exist. The contents of the file or the value of the registry key is allowed to change, so if it is changed, this does not make the installation “not intact”.  But if it is deleted, then the installation becomes “not intact”.

Q2: Why does Windows Installer repair product A if I launched product B?
A2: Very often, product A installs various hooks in the system, and they are used by all applications, including product B. For example, Adobe Reader installs certain extensions in Windows Explorer, which allows full-text searching in PDF files – i.e. you can search in Windows Explorer for all files containing a certain phrase, and Explorer will be able to find that phrase in PDF files – thanks to the extension installed by Adobe Reader. Another function of the extension is generating thumbnails of PDF files for Windows Explorer. This means that whenever you open a folder in Windows Explorer, Adobe Reader’s extension gets activated.  And since Adobe Reader has been installed with resiliency, this means that whenever you open a folder, the system verifies if the Adobe Reader extension is intact. If it’s not, then it will launch the self-repair process.

Q3: But why is it launched every time?
A3: Because it either fails to repair, or because it’s trying to repair a file that the application itself later removes during its regular operation. Such files should not be included in resiliency, but nothing prevents the author from including them; and if the author’s InstallShield or Wise warns them that a certain component has no resiliency information (by highlighting components with no keypath), the author will often blindly comply and create keypaths, even when in fact they are not required.

From this article I came across another article by the same author and here he talks about the Darwin Descriptor. Basically, the Windows installer used to be called Darwin and you can have registry keys that look like garbage but which actually tell it to go and do an integrity check and do self-repair if required. I’d suggest going and reading that article as the author explains it clearly but here’s how it helped me.

Let’s start with one of the Application log errors:

Using Orca  I found the component {86BFF64E-1771-4EF1-991C-C6A99F9690A6}.

By the way, Orca calls it ComponentID, so the Component as far as Orca is concerned is “WSO27AddinsShim.dll.471442DE_0EAA_4BBD_B726_5348144025DB”. Just for kicks, note that it points to a directory called “INSTALLDIR.471442DE_0EAA_4BBD_B726_5348144025DB”.

In the Directory table of the MSI I can find that this points to a “INSTALLDIR”, which in turn is a sub-folder of “WORKSITE”, which in turn is a sub-folder of “INTERWOVEN”, which in-turn is in the Program Files folder. So basically “INSTALLDIR.471442DE_0EAA_4BBD_B726_5348144025DB” points to “Program Files\Interwoven\WorkSite”.

I couldn’t capture it in the above screenshot, but that row also contains a column called KeyPath with the following: “wso27addinsshim.dll.471442DE_0EAA_4BBD_B726_5348144025DB”. Looking at the File table I can find that this points to a file called “WSO27A~1.DLL” (the 8dot3 file name) or “WSO27AddinsShim.dll” (the long name) of version 9.0.6.100 and size 123144 bytes – which I confirmed does exist in the directory path above.

OK, so as of now I have identified the component that is giving an error during integrity check and confirmed that the file it refers to actually exists. So there’s no reason for the integrity check to fail, and anyways if it is failing I can convince myself that it is safe to disable it somehow because the file in question does exist. How do I disable that? For this I went to the Registry table in Orca and found the entries created by the “WSO27AddinsShim.dll.471442DE_0EAA_4BBD_B726_5348144025DB” component. Among the many entries it was creating I found one with the CLSID: CLSID\{37a96034-eb52-4509-96a2-8aee5ea2c093}\InprocServer32. So I went over to HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{37a96034-eb52-4509-96a2-8aee5ea2c093}\InprocServer32 and found a value called InprocServer32 with the following: DC3E4j?Pc8'Y%mIPIlQXFileSite_x86>BzW5J%'5q?se1OG%XntL.

From the article above I knew that I knew that this gibberish was basically telling Windows to do an integrity check and repair of the FileSite_x86 feature (and if you read one of the articles I linked to earlier a feature contains other features and components, so by telling Windows to do an integrity check on the FileSite_x86 feature it was basically triggering the integrity check and repair of a whole other bunch of components – see screenshot below from the FeatureComponents table).

Anyhow, to fix this I went ahead and deleted the InprocServer32 value. I did the same for the CLSID of the other component that was giving an error, and with these two fixes I was effectively able to stop the integrity check and self-repair for FileSite from happening when I launched Outlook, Word, or Excel. It remains to be seen if I encounter new issues because I missed out on adding any files or registry keys expected by FileSite that were previously being added by the self-repair, but we’ll cross that bridge when it comes. :)

Update: Some more links I came across later.

 

Notes of PowerShell DSC course, OneGet & Chocolatey

Spent the past hour and half attending this course – Getting started with PowerShell Desired State Configuration (DSC) Jump Start, by Jeffrey Snover (inventor of PowerShell) and Jason Helmick. Had to give up coz my connection quality is so poor it kept freezing every now and then. Better to wait 2-3 weeks for the recorded version to be released so I can download and view. It’s a pity I couldn’t watch this though. I was looking forward to this course very much (and also its sequel Advanced PowerShell Desired State Configuration (DSC) and Custom Resources same time tomm which I will now have to skip).

From the little bit that I did attend, here are some notes.

Desired State Configuration (DSC)

  • Desired State Configuration (DSC) is meant to be a platform. You have tools that can manage configuration changes. And you have the actual items which you configure. Usually the tools are written specifically for the item you wish to configure. So, a certain tool might be good at managing certain aspects of your environment but not that great at managing other aspects. What Microsoft’s goal here is to offer a platform for configuration tools. Jeffrey likens it to Word Processors and printers in the past. Whereas once upon a time Word Processors were tied to printers in that certain Word Processors only worked with certain printers, once Windows OS came along and it had the concept of print drivers, all that was required was for printer manufacturers to provide drivers for their model and Word Processors to target this driver model and soon all Word Processors could print to all printers. DSC has a similar aim. 
  • DSC tends to get compared to GPOs a lot because they do similar things. But, (1) GPOs require domain joined machines – which DSC does not require – and (2) with a GPO you don’t have a way of knowing whether the policy applied successfully and/ or what failed, while with DSC you have insight into that. Other differences are that GPOs are tied to Windows whereas DSC is standards based so works with Linux and *nix (and even network switches!). 
  • DSC is Distributed & Heterogeneous. Meaning it’s meant to scale across a large number of devices or various types. 
  • Local Configuration Manager (LCM) is a WMI agent that’s built into PowerShell 4 and above. It is the engine behind DSC? (The presenters were starting to explain LCM in Module 2 which is when I finally gave up coz of the jerkiness).
  • Windows Management Infrastructure (WMI) has an open source counterpart (created by Microsoft?) called Open Management Infrastructure (OMI) for Linux and *nix machines. This is based on DMTF standards and protocols. Since LCM is based on WMI whose open source counterpart is OMI, LCM can work with Linux and *nix machines too. 
  • DevOps model is the future. Release a minimal viable product (i.e. release a product that works with the minimum requirements and then quickly keep releasing improvements to it). Respect reality (i.e. release what you have in mind, collect customer feedback (reality), improve the product). Jeffrey Snover recommends The Phoenix Project, a novel on the DevOps style. 
    • Windows Management Framework (WMF) – which contains PowerShell, WMI, etc – now follows a DevOps style. New releases happen every few months in order to get feedback. 

OneGet and friends

  • NuGet is a package manager for Visual Studio (and other Windows development platforms?). Developers use it to pull in development libraries. It is similar to the package managers for Perl, Ruby, Python, etc. I think.
  • Chocolatey is a binary package manager, built on NuGet infrastructure, but for Windows. It is similar to apt-get, yum, etc. Chocolatey is what you would use as an end-user to install Chrome, for instance.
  • OneGet is a package manager’s manager. It exposes APIs for package managers (such as Chocolatey) to tap into, as well as APIs for packages to utilize. OneGet is available in Windows 10 Technical Preview as well as in the WMF 5.0 Preview. Here’s the blog post introducing OneGet. Basically, you can use a set of common cmdlets to install/ uninstall packages, add/ remove/ query package repositories regardless of the installation technology.

To my mind, an analogy would be that OneGet is something that can work with deb and rpm repositories (as well as repositories maintained by multiple entities such as say Ubuntu deb repositories, Debian deb repositories) and as long as these repositories have a hook into OneGet. You, the end user, can then add repositories containing such packages and use a common set of cmdlets to manage it. This is my understanding, I could be way off track here … 

Installing WMF 5.0 preview on my Windows 8.1 machine, for instance, gets me a new module called OneGet. Here are the commands available to it:

As part of the course Jeffrey mentioned the PowerShell Gallery which is a repository of PowerShell and DSC stuff. He mentioned two modules – MVA_DSC_2015_DAY1 and MVA_DSC_2015_DAY2 – which would be worth installing to practice what is taught during the course. The PowerShell Gallery has its own package manager called PowerShellGet which has its own set of cmdlets. 

Notice there are cmdlets to find modules, install modules, and even publish modules to the repository. One way of installing modules from PowerShell Gallery would be to use the PowerShellGet cmdlets. 

Notice that it depends on NuGet to proceed. My guess is that NuGet is where the actual dependency resolution and other logic happens. I can install the modules using another cmdlet from PowerShellGet:

Now, the interesting thing is that you can do these operations via OneGet too. Because remember, OneGet provides a common set of cmdlets for all these operations. You use the OneGet provided cmdlets and behind the scenes it will get the actual providers (like PowerShellGet) to do the work. (Update: Turns out it’s actually the reverse. Sort of. Install-Module from PowerShellGet actually invokes Install-Package -Provider PSModule from OneGet. This works because PowerShellGet hooks into OneGet with so OneGet knows how to use the PowerShellGet repository). 

Remember, the find-* cmdlets are for searching the remote repository. The get-* cmdlets are for searching the installed packages. PowerShellGet is about modules, hence these cmdlets have the noun as module. OneGet is about packages (generic), so the noun has package

Very oddly, there seems to be no way to uninstall the modules installed from the PowerShell Gallery. As you can see below Uninstall-Module does nothing. That’s because there’s no uninstall cmdlet from PowerShellGet

I installed the xFirefox module above. Again, from the course I learnt that “x” stands for experimental. To know more about this module one can visit the page on PowerShell Gallery and from there go to the actual module DSC resource page. (I have no idea what I can do with this module. From the module page I understand it should now appear as a DSC resource, but when I do a Get-DSCResource it does not appear. Tried this for the xChrome module too – same result. Other modules, e.g. xComputer, appear fine so it seems to be an issue with the xFirefox and xChrome modules.)

Notice I have two repositories/ sources on my system now: Chocolatey, which came by default, and PowerShell Gallery. I can search for packages available in either repository. 

OneGet is working with Chocolatey developers to make this happen. Currently OneGet ships with a prototype plugin for Chocolatey, which work with packages from the Chocolatey repository (note: this plugin is a rewrite, not a wrapper around the original Chocolatey). For instance, here’s how I install Firefox from Chocolatey:

OneGet & Chocolatey – still WIP

Even though Firefox appeared as installed above, it did not actually install. This is because Chocolatey support was removed in the latest WMF 5.0 preview I had installed. To get it back I had to install the experimental version of OneGet. Here’s me installing PeaZip:

For comparison here’s the same output with the non-experimental version of OneGet:

As you can see it doesn’t really download anything …

Here’s a list of providers OneGet is aware of:

ARP stands for Add/ Remove Programs. With the experimental version one can list the programs in Add/ Remove programs:

The MSI and MSU providers are what you think they are (for installing MSI, MSP (patch) and MSU (update) packages). You can install & uninstall MSI packages via OneGet. (But can you specify additional parameters while installing MSI? Not yet, I think …)

That’s it then!