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.

 

[Aside] Profile Manager NTUSER.DAT editing

I liked this blog post. That’s something I had thought of trying earlier when I was thinking about registry keys and applying them via GPP vs other methods. For now I am applying a huge bunch of my registry keys via the default profile and if there’s any subsequent changes then I’ll push the change out via GPP (for existing users) and also modify the default profile (for new users). But the geeky method the author followed of loading each user’s NTUSER.DAT and modifying the registry key directly is fun and something I had considered. Only catch though is that this has to be done during a period no users are logged in. Coz of this I don’t think I’ll be trying this in my environment but I liked the idea.

Registry keys for various settings

Continuing in the vein of my previous post where I want to try and apply more settings via registry key changes to the default user profile as opposed to a GPO change, I thought I should have one place where in I can put the info I find.

Setting the wallpaper

Via this forum post.

Bear in mind this works like a preference not a policy. Users will be able to change the theme and wallpaper. That’s not what I want, so I won’t be using this – but it’s good info to have handy.

Setting IE proxy settings

By default Windows has per user proxy settings. But it is possible to set a registry key so the proxy settings are per machine.

Setting the color scheme in Server 2012

Via Server Fault: two registry values at HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM.

I’ve linked to this earlier, but this seems to be a good place to link to again: changing the start menu colors and background solid colors etc.

Drive Mappings

Look under HKCU\Network.

Environment Variables

Look under HKCU\Environment.

Changing the location of the default profile

Go to HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CurrentVersion\ProfileList and change the value of Default.

Removing the list of newly installed apps

Via this blog post:

Go to HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced and add a value called Start_NotifyNewApps of data 0 and type DWORD.

I am feeling less enthusiastic about replacing GPPs with a default use profile. I like the idea and it’s fast but the problem is that I can imagine users making changes and hence their profiles not being consistent with others. At least with GPPs I know there’s a baseline I can expect as the registry keys I expect will be present in the user profile; but with a default profile I have no such guarantee. If a user goes on and deletes one of my default registry keys, it won’t come back on next login unless I delete the profile.

Started thinking of mandatory profiles and came across this XenApp best practices post from Citrix. Probably wont go that route either but it’s good to keep in mind.

Importing Registry keys via GPP. Also, item-level targeting.

I wanted to do two things. 1) Import a bunch of registry keys for all users. And 2) Set some key values differently for users depending on their location.

Basically these were registry keys containing the details of all our WorkSite databases and I wanted to enable Auto Login to the local WorkSite DMS of each user. So basically import all the registry keys, and if a user’s location is XYZ (preferably identified via an LDAP query to the l attribute) set the DMS of that site to be AutoLogin.

Found this helpful post on how to export a registry key and convert it into an XML file you can copy paste in Group Policy Preferences. Damn! Nice one.

Next I created a copy of the key in question, set it to a higher number in the order (that happens by default when you do a copy) (we need it to be a higher number so that it overrides the other copy of that same key), and in its properties I enabled item-level targeting based on LDAP. Used a query like this: (&(objectClass=User)(sAMAccountName=%USERNAME%)(l=Dubai))

Some screenshots:

Here are the two keys I mentioned. The second one (with a higher order, 9) is set to a different value. The one with higher order will over-ride the one with lower order.

UPDATE: I was wrong. The lower number has higher precedence, so my screenshot above is wrong. I have hence swapped the order. The order is similar to that of GPOs. Lower number wins.

UPDATE 2: Maybe I wasn’t wrong after all. :) Even with the precedence change this didn’t work. I didn’t troubleshoot more (I suck, I know) – instead I just split these into separate GPOs. One to apply all the default settings, and one with higher precedence but scoped to the group I want to apply the different setting to. That did the trick.

I have set the higher order value to target specific users only though.

In this case, if the query searches for an User class object of matching login name and city (the l attribute) set to either Dubai or Abu Dhabi (the two offices for whom I want this key to be different).

Windows Services – Fix unquoted path vulnerabilities using PowerShell

At work as part of some security certification we are running Nessus scans on all our systems and it came up with the following vulnerability – link. Read that link, it’s good info.

Basically if one of your Windows Service entries point to (say) “C:\Windows\Microsoft.NET\Framework64\v3.0\Windows Communication Foundation\SMSvcHost.exe” without the double quotes then one could potentially create a malicious file called Windows.exe at “C:\Windows\Microsoft.NET\Framework64\v3.0\Windows” and Windows will execute that file instead of parsing the full path and treating it as part of a folder name. That’s because Windows uses space as a delimiter between a command and its switches & arguments and so it could treat the entry as “C:\Windows\Microsoft.NET\Framework64\v3.0\Windows.exe” with arguments “Communication Foundation\SMSvcHost.exe“.

The solution for this is to find all such entries that contain a space, and if the path is not in double quotes then make it so. You have to do this in the registry, so you could either do it manually or make a script and do it en masse. I went the latter route so here’s something I created.

I am being lazy and not really offering input etc as I just expect a list of servers to be scanned in a file called “ServerNames.txt”. I have the above saved to a .ps1 file and I simply run it as .\Registry.ps1. Feel free to adapt to your needs.

What it does is that it connects to the server specified (provided they are online), tries to open the “services” key under HKLM (assuming it has access), and then enumerates all the subkeys that contain the service names and checks if the path has a space. It only matches against paths containing a .exe so it could miss out some stuff. Once it finds a match it extracts the bit up to the .exe, splits it along any spaces, and if there are more than one results (which means the path did have spaces) it encloses it in double quotes and replaces the original entry.

The code is smart enough to know it must correctly double quote something like "D:\Program Files (x86)\BigHand\BigHand Workflow Server 4.6\BHServer.exe /V:4.6" as "D:\Program Files (x86)\BigHand\BigHand Workflow Server 4.6\BHServer.exe" /V:4.6 and not "D:\Program Files (x86)\BigHand\BigHand Workflow Server 4.6\BHServer.exe /V:4.6".

By default it only displays results. An optional parameter -FixIt will also make the changes.

Example output:

Hope it helps!

Windows – View hidden network interface IP address

Was troubleshooting something in VMware, I ended up copying the actual files of a VM from one datastore to another and re-adding it to a host (because the original host was stuck entering into maintenance mode and I needed this VM to sort that out blah blah … doesn’t matter!). Problem is when I did the re-adding and vCenter asked me if I copied or moved the VM, I said I copied. This resulted in all the network interfaces getting new MAC addresses (among other changes) and suddenly my VM was without any of the previously configured static IPs!

Damn.

The old interfaces are still there just that they are hidden.

I used PowerShell/ WMI to list all the network interfaces on the server (this shows the hidden ones too).

In the Network Connections GUI all I can see are the last two adapters, so everything else is hidden. If I just wanted to delete them I would have followed the instructions in this post. (When following the instructions in that post be sure to enter set devmgr_show_nonpresent_devices=1 on a line of its own).

The ones starting with “vmxnet3” are what’s of interest for me so let’s focus on that. 

The reason I focused on SettingID is because if you check under HKLM\SYSTEM\ControlSet001\services\Tcpip\Parameters\Interfaces you’ll find entries with these GUIDs.

With a bit of PowerShell you can enumerate these keys and the IP address assigned to it:

My PowerShell skills are getting worse by the day due to disuse so the above is not probably the most elegant way of doing this. :)

Anyways, by comparing the two outputs I was able to identify the missing IP as either 10.136.37.36 or 10.134.203.2. The latter was of a different network so it looked like an older hidden adapter. I set the former, and as expected the network started working. Yay!

 

Solving “Btsync:// Protocol Not Available” errors (or how to register a new protocol in Windows)

I have BitTorrent Sync. It was installed a long time ago and automatically updated over the years. I guess the initial installs never registered the Btsync protocol because today I emailed myself a link to a shared folder on my phone and when I clicked the link on the computer nothing happened. I was using Chrome so I tried it under Internet Explorer and Firefox. The former gave the error above, the latter said the address wasn’t understood and explained that it doesn’t know what program to use for the btsync protocol. Good, at least these were clearer on what the issue was. (Moreover Firefox even showed the full address in the address-bar – btsync://link.getsync.com/?f=DCIM&sz=64E7&s=BBBBB...XXXXGRPQ5&i=CFFFF...KG&p=CAAAA...7AB&e=146...3 – kudos to it!)

I haven’t added a new protocol/ extension to Windows for a long while, and while I could modify the protocols/ extensions for existing entries under “Default Programs” in the Windows control panel (I am using Windows 8.1 Update 1 by the way) there was no option to add a new protocol. Never mind, it’s possible via the registry. See this link on more details, the upshot of it is that you can create registry keys under HKEY_CLASSES_ROOT to register new protocols or file extensions. Below is what I created for Btsync, copy paste this into a text file with the extension .reg, change the program paths if your installation is in a different folder (quite possible if you have the 64-bit version for instance), then double click the file and say OK to importing it. 

That’s it! Now BitTorrent launches as expected. Hope this helps someone …

Tip: Overriding a GPO setting via Registry

At work our Desktops team has put a policy in place that enables Outlook cached mode for every one. Which becomes a pain in the a$$ when you have to disable and enable cached mode for some users as part of fixing issues (OST file corruptions, no incoming emails, etc).

Thankfully this is a setting you can temporarily override via the registry. Just got to modify a key under HKCU.

But … if you open the registry as the affected user and try modifying the key, you can’t because of lack of permission. Expected, right? What’s the point of a policy if users can modify the registry directly to override it. Admin users can modify the key, but if you open the registry as an admin then HKCU points to the admin and not the user.

Here’s how you workaround though: open the registry by doing a “run as” as the admin. Then go to HKEY_USERS. One of the entries there will be for the user logged in. (There shouldn’t be many entries, but if there are then you can find the one you want in one of two ways: (1) Use psgetsid from the Sysnternals tools to find the SID of the logged in user. That’s the entry you want. Or (2) go to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. You will find entries there with the same names as under HKEY_USERS. Check the ProfileImagePath key in each – the one with the path to the logged in user is the key you want).

Once you find the key of the logged in user under HKEY_USERS that’s it. Everything under here is the HKCU of the logged in user so any changes you make here reflect HKCU. Go ahead and change whatever you want – the change will succeed because you are now using an admin account to make changes to the logged in user’s HKCU. Hah!

Hope this helps someone.

Recreating Windows profiles; Internet Explorer passwords

I had to recreate a user’s Windows profile the other day and made the novice mistake of removing the profile from his computer by just deleting the folder from c:\Users. Not a good idea coz that leaves all the registry stuff behind. The correct way to remove his profile would have been to go via the System properties, User Profiles, and then delete the profile. If it complains about the folder not being removed, then remove the folder.

What happened in my case since the registry stuff was still leftover is that Windows wouldn’t create a new profile folder because it thought the profile folder had an error. It kept logging the user in with a temporary profile and complained so: “You have been logged on with Temporary profile”.

Worse, I always thought HKEY_USERS was where all the registry stuff was stored so that’s where I kept looking to try and delete the registry bits manually. Finally I realized it’s under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList – doh! HKEY_USERS only has the registry hives for actively loaded profiles – not necessarily the one logged in interactively, but also user accounts running in the background or that have recently run (via “run as” etc).

So I went to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList, found the profile (which now had a .bak suffixed to it), deleted it (because I want him to start afresh), and that got things working again.

After recreating the profile the user told me he wanted his Internet Explorer saved passwords. These are stored under HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2 but I hadn’t saved his HKCU hive before deleting the profile. Not a problem – I had a backup of the profile folder, so I:

  1. Copied the NTUSER.DAT file from there to my computer (NTUSER.DAT is basically the HKCU hive for his account),
  2. Loaded it into my registry as a temporary hive,
  3. Exported ...\Software\Microsoft\Internet Explorer\IntelliForms\Storage2 from this temporary location to a .reg file,
  4. Opened this file in notepad and renamed the root to HKEY_CURRENT_USER.

I then sent the .reg file to the user and once he opened it the passwords were imported into his registry.

Here’s the command I ran from an elevated command prompt to load the ntuser.dat file to a temporary location HKLM\TempHive:

Using the above temporary location, I had to rename HKLM\TempHive to HKEY_CURRENT_USER once I exported the key and opened in notepad.

How to get a list of COM objects from the registry

Today I was looking for the COM ProgID for Excel on my machine and my previous approach of using WMI didn’t work.

That’s not correct as I can create a new COM object by referring to Excel.Application.

Since ProgIDs are found in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Classes I figured that would be a good place to get an exhaustive list from. Under this key there are three types of subkeys:

  1. Subkeys for each file extension registered with the system, each of which has a (Default) entry with the ProgID and also a subkey with the ProgID. Not all these ProgIDs seem to be valid though (based on my testing), so it’s best to go by the other set of subkeys detailed below.
  2. Subkeys for each ProgID – usually of both ProgID formats <Program>.<Component>.<Version> and <Program>.<Component> – again, not all valid, but a good test of validity (based on my testing) being whether they contain a subkey called CLSID.
  3. Subkeys such as “Unknown”, “Undecided”, etc and also some that look like ProgIDs but are not in the correct format (for instance: they don’t contain the <Component>.<Version> bit, or contain spaces and underscores (not allowed)

So a sensible way to filter out ProgIDs seems to be to check for subkeys of the format <Program>.<Component>.<Version> (the <Version> being optional) and to further filter out those which have a CLSID subkey.

Thus we have the following:

And to search for a specific application, one can do: