Subscribe via Email

Subscribe via RSS/JSON


Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan


How to remove complex scripts from Word DOCX documents

Recently came across a Word document where some parts of the document seemed to ignore the general rules. The document was in English, and its language was set to English (U.S.) but certain parts were set to Arabic (Saudi) and none of the usual methods of selecting the text and marking it as English (U.S.) was helping. Very weird.

After a lot of fiddling around I also noticed that if I change the style of a paragraph containing such text, the adjoining text changes but this particular one stays as it. I am able to change the font and size directly by applying them, but changes via styles seem to get ignored.

Then I realized that although this text was in English, since it was marked as Arabic (Saudi) they were being treated as “complex scripts” in the style definitions and hence had separate rules. I guess that at some point someone had marked this text as of being Arabic (Saudi) and continued typing in English, or perhaps the original text was Arabic but someone had changed the font to an English one like “Times New Roman” and typed in English, so even though the text was appearing as English in fact Word was treating it as Arabic written in English (I guess). Anyways, point was Word was treating these blocks as complex scripts (as opposed to Latin for other parts) and so the usual formatting rules didn’t apply to them. Moreover I could change the language from Arabic (Saudi) to Arabic (UAE), for instance, so that seemed to support my theory that it was letting me changing the language to other complex scripts – just not from complex to Latin and vice versa.

This being a DOCX file, it is really just a zip file. So I unzipped it using 7-Zip. Went to the word\styles.xml file (which I came across through trial and error actually, I went through pretty much all the XML files there) in the extracted folder and found the  following:

Since I didn’t want the document to have any Arabic at all, I simply changed the “ar-SA” to “en-US”. Saved the XML file, went back to the extracted folder, and zipped all its contents up again. Renamed this from .zip to .docx and opened the document, and bingo! now all that complex stuff weirdness was gone! :)

(A word to note about zipping back the folder. The format is ZIP. And also, don’t zip the top level folder as then your zip file will be the top level folder followed by all the sub-folders. No, what we want is that the zip file is all the sub-folders directly).

Using PowerShell to find Computer objects in AD that have inheritance disabled

I needed to find the computer objects in an AD OU that had inheritance disabled. Did the following:

And to extend this to enable inheritance on the affected objects:

Deleting credentials from Credential Manager remotely

The title is a bit misleading, but whatever. I wanted to delete the credentials in Windows Credential Manager on a remote machine. I didn’t want to delete any particular credential – what I suggest below won’t work for that – but simply all the credentials stored for a particular user.

What you need to do is go to the C: drive of that remote machine and then C:\Users\<the user>\AppData\Roaming\Microsoft\Credentials. You may not see anything here as they are System files and hence hidden. But once you do the needful to see them, delete all the files present here and the credentials are removed.

[Aside] How to roam AppData\Local too

Came across this video from James Rankin. Apart from being an excellent video, it has one important thing which I felt I must note down here as a reference to myself. I always thought AppData\Local and AppData\LocalLow were not synced as part of your roaming profile because they were special in some way. Today I realized that there’s nothing special about them. They are not synced because of a key called ExcludeProfileDirs in HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. Any folder mentioned there is not synced as part of your roaming profile. Nice!

So to make AppData\Local roam, simply remove it from that registry key. Then selectively add any sub-folders you might want to exclude.

XenApp and Run/ RunOnce keys

Reminder to myself: the Run and RunOnce entries in HKLM and HKCU are not processed if an application is launched via XenApp. That’s because these keys are processed by explorer.exe and that doesn’t run when you launch single applications (as opposed to the desktop).

Adding multiple languages via Registry

I wanted to have multiple languages/ keyboard layouts in my XenApp environment. Thought I’d push it out via a registry key change. I forget the blog post I had found the details from but this one has similar info. Basically HKEY_CURRENT_USER\Keyboard Layout has the registry keys you need to modify. Easiest thing to do is add the languages and keyboards you want via GUI (control panel) and then just export the registry keys. My example below has English UK, English US, and Arabic.

This is a good blog post that explains the keys above and also gives a way of deploying this via GPO (i.e. using admin templates).

Set 7-Zip as the default for zip files

Had to do this for my XenApp install (7-Zip on a Server 2012R2). Thanks to this post which is in turn based on this post. Trick is to put the following into a registry file and double click/ import it on the machine:

After this go to Control Panel > Default Programs and 7-Zip will appear there. You can set it as the default for all extensions/ choose the ones you want.

Update: Frustratingly, I learnt that the Control Panel way doesn’t do the trick for Citrix. Later I learnt that maybe HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\ might be where FTAs (file type associations) are stored, so spent some time exporting the keys from there and pushing out via GPO. Turns out that didn’t do the trick either as it includes a hash tying the file type association to the user & machine where it was set to (bummer eh!). Thanks to these two posts [1][2] I learnt that the official approach is to use DISM to export the FTAs for a user and then deploy it via GPO. The FTAs are deployed to machines, so you can’t have per user customizations this way (but the two posts above have some workarounds).

The DISM command is: dism /online /Export-DefaultAppAssociations:c:\ftas.xml.

Update2: Here’s a blog post containing a tool that lets you bypass this hash issue.

Update3: This is a blog post about the OEMDefaultAssociations.xml. This is the file where the default customizations are stored, which you can over-ride via GPO. Or you could edit this file itself per machine. I learnt via trial and error – this file is very sensitive. If there are missing entries (the default ones) or even out of order entries it seems to be ignored altogether.

The entries in this are configured on new user profiles (existing ones are left untouched) and users can modify the associations if they want. The entries in the GPO cannot be changed by users.

Firefox Offline Installers

For my own info –

Good to have these in case you are not connected to the Interwebs and wan’t to install Firefox.

Also, this link on how to set a proxy in Firefox for all users.

[Aside] Always offline mode for cached files

I wasn’t aware of this until a few weeks ago. Starting with Windows 8/ Server 2012 there’s an always offline mode for cached files and folders. That’s useful!

[Aside] How to convert a manually added AD site connection to an automatically generated one

Cool tip via a Microsoft blog post. If you have a connection object in your AD Sites and Services that was manually created and you now want to switch over to letting KCC generate the connection objects instead of using the manual one, the easiest thing to do is convert the manually created one to an automatic one using ADSI Edit.

1.) Open ADSI Edit and go to the Configuration partition.

2.) Drill down to Sites, the site where the manual connection object is, Servers, the server where the manual connection object is created, NTDS Settings

3.) Right click on the manual connection object and go to properties

4.) Go to the Options attribute and change it from 0 to 1 (if it’s an RODC, then change it from 64 to 65)

5.) Either wait 15 minutes (that’s how often the KCC runs) or run repadmin /kcc to manually kick it off

While on that topic, here’s a blog post to enable change notifications on manually created connections. More values for the options attribute in this spec document.

Also, a link to myself on the TechNet AD Replication topology section of Bridge All Site Links (BASL). Our environment now has a few sites that can’t route to all the other sites so I had to disable BASL today and was reading up on it.

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 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] Finding the source of a domain account lockout

An excellent post. Easy and to the point. Wish I had discovered this much before. The upshot is:

  • Enable debugging on a domain controller: nltest /dbflag:0x2080ffff
  • Disable debugging after a bit: nltest /dbflag:0x0
  • Check the logs at %windir%\debug\netlogon.log to find out where/ what is locking the account.

Asynchronous processing of Group Policy Preferences

My XenApp servers are set to process their GPOs synchronously (because I apply folder re-direction via GPO) and unless I do it synchronously there’s a chance that the user could login without folder redirection and only on the next login will folder redirection kick in.

However I have a bunch of registry keys I am setting via Group Policy Preferences (GPPs) and these take a long time. Eventually I decided to remove these from GPP and set in the default profile itself, and I have to figure out what to do later on when I need to make changes etc (I guess that’s still better as I only need to target the keys that need changing). But before I did that I was reading into how I can set GPPs to run asynchronously. I am ok with the registry keys being set after the user is logged in.

Well, turns out you can use Item Level Targeting (ILT) to have the GPP apply only in non-synchronous mode. I found this via this forum post.

If you want to do this en-masse for all your GPP registry keys you can edit the XML file itself where the GPP settings are stored. (Which is a cool thing about GPPs by the way – I hadn’t realized until now. All GPP settings, such as registry keys, shortcuts, etc. are stored in XML files in the policy. You can copy that XML file elsewhere, make changes, delete the GPP settings and copy paste the XML file into the GPP).

Anyhoo – in the XML file if your existing line for a setting is like this one (:

Add a new line like this after the above:

This adds a filter to that setting causing it to run only if the GPO mode is not synchronous.

This didn’t seem to make much of a difference in my case (in a very unscientific observation of staring at the screen while GPOs are being applied :)) so  I didn’t go down this route eventually.

On this topic, FYI to myself. By default GPPs are processed even if there is no change to the GPP. This is not the expected behavior. GPPs are called “preferences” so the impression one might get is that they set preferences, but let users change the settings. So I could have a GPP that sets an environment variable to something. The user could change it to something else. Since I haven’t changed the GPP after this, I wouldn’t expect GPO processing to look at the GPP again and re-set the environment variable. But that’s not what happens. Even if a GPP hasn’t changed, it is reconsidered during the asynchronous and background processing and re-applied. This can be turned off via GPO by the way. Lookie here: Computer Configuration\Administrative Templates\System\Group Policy\.

Totally unrelated, but came across as I was thinking of ways to apply a bunch of registry settings without resorting to GPPs: a nice article on the RunOnce process in Windows. Brief summary (copy pasted from the article):

  • The Windows registry contains these 4 keys:
  • HKLM\Software\Microsoft\Windows\CurrentVersion\Run
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run
  • HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
  • HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

HKCU keys will run the task when a specific user, while HKLM keys will run the task at first machine boot, regardless of the user logging in.

The Run registry keys will run the task every time there’s a login. The RunOnce registry keys will run the taks once and then delete that key. If you want to ensure that a RunOnce key is deleted only if its task is run successfully, you can prepend the key name value with an exclamation mark ‘!’.


%TEMP% environment variable has a \2 or other number after it

For my XenApp servers I had set the TEMP and TMP environment variables via GPO to be the following: %USERPROFILE%\AppData\Local\Temp. But that seems to be ignored as all my users were getting these variables set to %USERPROFILE%\AppData\Local\Temp\2 or some similar number. Weird!

Reason for that is that there are 4 different contexts where a variable is set. I knew two of these and kind of knew the third of these, but I had no idea of the fourth one. These four contexts are:

  1. System variable – a variable that applies to all users of the system. These are stored at HKLM\System\CurrentControlSet\Control\Session Manager\Environment.
  2. User variable – a variable that applies to the currently logged in user. These are stored at HKCU\Environment.
  3. Process variable – a variable that you can apply to a particular process and its children. These are not stored in the registry. I kind of knew of such variables (though I hadn’t formalized them in my head) coz I knew you could launch a process and put a variable assignment before it to set the variable just for that process and its children. (Hmm, now that I think about it was that for Linux or Windows?)
  4. Volatile variable – a variable that applies to the current context of the currently logged in user. These are not saved between log offs or reboots. They are stored at HKCU\VolatileEnvironment.

Whoa! So volatile variables. I had no idea of these, but sure enough when I checked the registry location TEMP and TMP were set there just like I was seeing.

(All the above info was from this helpful TechNet page by the way).

I had no idea a single user could have multiple sessions open on a machine. Server or desktop, I was under the impression you were restricted to a single session; but I guess I was mistaken. From a forum post:

This concept was originally was created by Citrix when they produced WinFrame as a way of handling multiple user sessions on the same machine as a way to handle keeping each user’s temp location unique to each user. Microsoft added it to their OS subsequently as they added Windows Terminal Services to the OS, and this only happened when logging into a terminal services session.

With the evolution of the OS in the Vista timeframe, Micrsooft added the ability for you to have multiple users logged into the OS console at the same time and switch between user sessions, to do that they used the same concept borrowed from the Windows Terminal Services side of the OS.

It is just a mechanism to keep the temp variable locations unique and separate between users. The number used for the directory is actually the session ID number for the user session.

Anyhow, what can I do to fix this? Turns out we can disable this multiple TEMP folders per session thing via GPO. The relevant setting is under: Windows Components/Remote Desktop Services/Remote Desktop Session Host/Temporary folders. Here I set “Do not use temporary folders per session” to true and now I don’t have multiple TEMP folders. Since I don’t want separate sessions (mainly coz I don’t know what they are used for in terms of XenApp) I also went ahead and disabled that from Windows Components/Remote Desktop Services/Remote Desktop Session Host/Connections where you can find a setting called “Restrict Remote Desktop Services users to a single Remote Desktop Services session”.

TIL: HKEY_USERS\.DEFAULT is not the default user profile

I knew this already but came across again from this script Q&A and thought its worth reminding myself: HKEY_USERS\.DEFAULT is not the default user profile (i.e. the profile used as the default settings for a user who logs in and does not have an existing profile).

HKEY_USERS \.DEFAULT is the profile for the LOCALSYSTEM account. It is an alias for HKEY_USERS\S-1-5-18.

The registry settings used as the default settings for a user who logs in and does not have an existing profile are at C:\Users\Default\ntuser.dat.

Also pointing to this blog post that explains this in more detail.