Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Recent Posts

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

[Aside] Plug-ins not loading in Adobe Reader XI?

Disable Protected Mode:

Thanks to this forum post.

[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 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. :)

[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.

[Aside] NetScaler and WireShark

FYI to myself: NetScaler + WireShark. Lots of useful WireShark tips and tweaks.

[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.

Citrix – Word could not create the work file

I came across the problem outlined in this blog in our Citrix environment. It’s only got two test users (one of whom is me) and it only happened once to either of us, so I am not sure if it’s really the same thing or not.

The author’s findings are that it is because the %USERPROFILE%\AppData\Local\Microsoft\Windows\INetCache folder is missing. In my case the folder was present when I took a look, but maybe it got created – I dunno. The odd thing in my case was that I was trying to launch both Outlook and Word together and that’s when Word complained. Once I Word opened after Outlook had launched, it was fine. Also, oddly, this wasn’t the first time I had launched Word either. Previous attempts had worked fine.

What I did for now is add the above path to UPM to be synchronized. Hoping that helps. Else I’ll make a GPP like the author has suggested.

[Aside] Citrix StoreFront customizations & tweaks

As a reference to myself for the future:

Citrix not working externally via gateway; ICA file does not contain gateway address or STA

This is something that had me stumped since Thursday. I was this close to having my Citrix implementation accessible externally via a NetScaler gateway, but it wasn’t working. What was the issue? The ICA file did not have the gateway address, it only contained the internal address of the VDA and obviously that isn’t reachable over the Internet.

The ICA file had this (an internal address) (FYI: you can enable ICA logging to get a copy of the ICA file):

While it should have had something like this (STA info along with the external address of my gateway):

Everything was configured correctly as far as I could see, but obviously something was missing.

First question: who generates the ICA file? As far as I know it is the StoreFront, but was I sure about that? Because whoever was generating the ICA file wasn’t doing a good job of it. Either they were wrongly detecting my external connection attempt as coming internally and hence skipping out the STA etc. information, or they knew I was connecting externally but choosing to not input the gateway information. Found this excellent blog post (cached PDF version just in case) on the flow of traffic and that confirmed that it is the StoreFront who generates the ICA file.

  • Upon login via NetScaler (or directly) the StoreFront creates a page with all the available resources.
  • User clicks on a resource. This request makes its way to the StoreFront server – either directly or via NetScaler.
  • StoreFront contacts the XML/ STA service on the Delivery Controller which will decide where to launch the resource on (which server/ desktop etc).
  • The XML/ STA service will put all this information in an STA ticket (basically an XML file) and send back to the StoreFront server.
  • The StoreFront will create an ICA file and send to the user. The ICA file is based on a template, per store, and can be found at C:\inetpub\wwwroot\Citrix\<store>\App_Data\default.ica.
    • Depending on whether the connection is internal or via gateway the StoreFront server will put in the correct address in the ICA file. (We will come back to this in a bit)
  • The StoreFront passes this ICA file to the gateway if its an external connection, or to the receiver / browser directly if its an internal connection.

Ok, so the StoreFront is the one who generates the ICA file. So far so good.

How does the StoreFront know the connection is via a gateway? There’s this thing of “beacons” which is supposed to help detect if a connection is external or internal but that’s used by the receiver, not by the StoreFront. Basically a store has an internal URL and an external URL (via gateway) and once you add a store to Citrix Receiver the Receiver uses beacons to identify if its internal or external and use the correct URL. Note: this is for connecting to a store – i.e. logging in and getting a list of resources etc, nothing to do with ICA files or launching a resource (which is what I am interested in).

StoreFronts have a list of gateways corresponding to the various NetScaler gateways that can connect to its stores. Each gateway definition contains the URL of the gateway as well as a NetScaler SNIP address (now optional; the article I link to is a good read btw). When a connection comes to the StoreFront it can match it against the gateway URL or the SNIP (if that’s defined) and thus identify if the connection is external or internal. (When a user connects through, the StoreFront will attempt to authenticate it against the gateway URL so make sure your StoreFront can talk to the gateway. Also, if the gateway URL has a different IP and you can’t modify DNS with the internal IP, then put an entry in the hosts file).

So how to find out whether my connections via gateway were being considered as internal or external? For this we need to enable debug logging on the StoreFront.This is pretty straight-forward actually. Log on to the StoreFront server, open  PowerShell with admin rights, and run the following cmdlets:

Then we need to download DebugView from SysInternals and Click Capture and select Capture Global Win32. In my case I could see in the debug console straight away that the connection was being detected as external:

Hmm, so all good there too. StoreFront was definitely detecting my connection as external and yet not putting in the gateway address.

At this point I hadn’t enabled access from my NetScaler to the internal VDAs (because I hadn’t reached that stage yet). So I modified my firewall rules to allow access from the NetScaler SNIP to my XenApp subnet. Still no luck.

On a side note (something which I wasn’t previously clear on and came about while reading on this issue): when defining a gateway on the StoreFront the Callback URL is optional and only required for SmartAccess. Basically a NetScaler gateway can work in Basic/ ICA proxy mode or SmartAccess (full VPN?). I was using the gateway as an ICA proxy only so there was no need for the Callback URL (not that removing it made any difference in my case!).

Also, if you are using two-factor authentication on the gateway then the logon type in the gateway definition should say “Domain and security token”.

This blog post by the amazing Carl Stalhood on StoreFront configuration for NetScaler gateway is a must-read. If nothing else it is a handy checklist to make sure you haven’t missed anything in your configuration.

Also a quick shout-out to this great post on troubleshooting NetScaler gateway connection issues. It is a great reference on the whole process of connection as well as the ICA file and what you can do at each step etc. (One of the things I learnt from that post is that apart from the STA ticket the ICA file also contains an NFuse ticket – this is the previous name of Citrix StoreFront/ Web Interface and is found as a line LogonTicket= in the ICA file).

And since I am anyways linking to two great posts at this point, I’d like to re-link to a post I linked to above (from Bas van Kaam) explaining the XenApp logon flow etc.

Anyhow. After a whole lot of Googling I came across this forum post (in all fairness, I came across it as soon as I had started Googling, but I mis-read the suggestion the first few times). It’s a cool thing, so I’d like to take a moment to explain first before going on into what I had mis-configured.

At the firm where I work we have multiple sites. Each site has its own infrastructure, complete with Delivery Controllers, StoreFronts, and NetScaler gateway. Users of each site visit their respective gateway and access their resources. There’s nothing wrong with this approach just that it is kind of unnecessary for users to keep track of the correct URL to visit. We actually have a landing page with the gateway URLs of each of our sites and users can click on that to go to the correct gateway.

It makes sense to each site to have its own resources – the XenApp/ XenDesktop servers. It also makes sense to have separate Delivery Controllers per site – so they are close to the resources. And it makes super sense to have a NetScaler gateway per site so that user connections go from their remote location (e.g. home) to the site gateway to the XenApp/ XenDesktop resource. But we don’t really need separate StoreFront servers do we? What if we could have the StoreFront servers in a single location – serving all the locations – yet each user’s connecting to the resources in their location go via the NetScaler gateway in that location? Turns out this is possible. And this feature is called Optimal HDX Routing.

  1. We would have a NetScaler gateway in a central site. This site would also have a bunch of StoreFront servers.
  2. Each non-central site would have its own Delivery Controllers with VDA infrastructure etc.
  3. On the StoreFront servers in the central site we define one or more stores. To the stores we associate the Delivery Controllers in all the other sites.
  4. At this point a user could login to the gateway/ StoreFront in the central site and potentially connect to a resource in any of the sites. This is because the StoreFront is aware of the Delivery Controllers in all the sites. 
    1. I am not entirely clear which Delivery Controller the StoreFront would query though to get a list of resources (coz I am still figuring out this stuff). My feeling is this is where the concept of zones come in. I think once I create a zone I’d be associating users and Delivery Controllers to it so that’s how the StoreFront knows whom to contact.
  5. The StoreFront server in the central location passes on this info to its gateway (i.e the one in the central location).
  6. (fast-forwarding a bit) Say its a user in a remote site and they select a resource to use (in the remote site because they are mapped to it via zones). The request is sent to the StoreFront in the central location.
  7. At this point the StoreFront can launch the resource via the Delivery Controller of the remote site. But how should the user connect to this resource though? Should it connect via the NetScaler gateway in the central site – inefficient – or is there a way we can have a NetScaler gateway in each remote site and have the user connect via that?

The answer to that last question is where optimal HDX routing comes in. StoreFront doesn’t know of zones (though you can mention zones for info I think) but what it does know is Delivery Controllers. So what a StoreFront can do – when it creates an ICA file for the user – is to look at the Delivery Controller that is serving the request and choose a NetScaler gateway which can service the request. The StoreFront can then put this NetScaler gateway address in the ICA file, forcing the user to connect to the resource in the remote site via that remote NetScaler gateway. Neat huh!

I don’t think I have explained this as best as can be done so I’d like to point to this blog post by JG Spiers. He does a way better job than me.

Here’s what the issue was in my case. Take a look at this screenshot from the Optimal HDX Routing section –

Notice the default entry called “Direct HDX connection” and how it is currently empty under the Delivery Controllers column? Well this entry basically means “don’t use a gateway for any connections brokered by the listed Delivery Controllers” – it’s a way of keeping a bunch of Delivery Controllers for non-gateway use only. For whatever reason – I must have been fiddling around while setting up – I had put in both my Delivery Controllers in this “Direct HDX connection” section. Because of this even though my StoreFront knew that the connection was external, since the entry for my gateway (not shown in the screenshot) had no Delivery Controllers associated with it the StoreFront wasn’t returning any gateway address. The fix thus was to remove the Delivery Controllers from the “Direct HDX connection” section. Either don’t assign the Delivery Controllers to any section, or assign it to the entry for my gateway.

Here’s similar info from the Citrix docs. I still prefer the blog post by JG Spiers.

Took me a while to track down the cause of this issue but it was well worth it in the end! :)

Update: From a blog post of Carl Stalhood:

If you have StoreFront (and NetScaler Gateway) in multiple datacenters, GSLB is typically used for the initial user connection but GSLB doesn’t provide much control over which datacenter a user initially reaches. So the ultimate datacenter routing logic must be performed by StoreFront. Once the user is connected to StoreFront in any datacenter, StoreFront looks up the user’s Active Directory group membership and gives the user icons from multiple farms in multiple datacenters and can aggregate identical icons based on farm priority order. When the user clicks on one of the icons, Optimal Gateway directs the ICA connection through the NetScaler Gateway that is closest to the destination VDA. Optimal Gateway requires datacenter-specific DNS names for NetScaler Gateway.

That clarifies some of the stuff I wasn’t clear on above.

[Aside] Enable ICA file logging

Very useful when you are troubleshooting and want to see the ICA file received by the client/ receiver. Instructions at https://support.citrix.com/article/CTX115304.

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”.

[Aside] Citrix Storefront Sync Problems – Propagate Changes – Server is not reachable. Configuration settings might be out of date.

A quick thank you to this blog post for making my day slightly better today! Stumbled upon this issue and when a quick reboot and a look at the running services didn’t show any obvious errors I was at a loss of what to do. Wouldn’t have thought these two accounts were getting removed via GPOs. :)

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.

Notes on Server 2012 DHCP Failover

A bit confused on some terminology regarding Server 2012 DHCP failover in hot standby mode. I don’t think I am alone in this, and have been reading up on the same. Thought I’d put down what I read in a blog post as a reference to myself.

DHCP failover in load balancing mode is straight-forward so I am going to ignore it for now. In hot standby mode there’s a Maximum Client Lead Time (MCLT) and State Switchover Interval (SSI) that have me confused.

This article from Windows IT Pro is excellent at explaining these concepts. A must read.

Following are some notes of mine from this article and a few others.

  • The DHCP lease duration – i.e. for how long a client is leased the DHCP address.
  • In a hot standby relationship one DHCP server is active, the other is standby. The relationship can be in various states:
    • Normal – all is good.
    • Communication Interrupted – the servers are unable to contact each other and have no idea what the other is up to. They do not assume the partner is down, only that they are unable to communicate (possibly due to a break in the link etc).
    • Partner Down – a server assumes that its partner is down. This need not automatically happen. Either an administrator marks the partner as down, or we can set this to automatically happen after an interval (which is the State Switchover Interval mentioned above).

The Partner Down state is easy. The standby server knows the active server is down and so it must take over. No problemo. From the time the standby server cannot contact the active server, wait for the State Switchover Interval duration and then take over the leases. Essentially progress from being in a Normal state to a Communication Interrupted state, wait for the State Switchover Interval duration, and if no luck then move to a Partner Down state.

It’s worth bearing in mind that the standby server takes over the lease only after it is in a Partner Down state. While operating in a Communication Interrupted state it only makes use of addresses from its reserved pool (by default 5% of the addresses are reserved for the standby server; this figure can be changed).

The Communication Interrupted state is a bit tricky.

  • If the standby server is cut off from the active server, and all the clients too are partitioned along with the active server, then there’s nothing to do for now – since the clients can’t contact the standby server it won’t get any requests for IP addresses anyways.
  • However, if all/ some of the clients aren’t partitioned along with the active server and can contact the standby server, what must it do?
    • If the request is for a new address, the standby server can assign one from its reserved pool. But it has no way of informing its partner that it is doing so, and since it can’t assume the partner is down it must work around the possibility that the partner too might eventually assign this address to some client. In fact, the partner/ active server too faces the same issue. If it gets a request for a new address while in the Connection Interrupted state, it can assign one but has no way of informing its partner/ standby server that it is doing so. What is required here thus is a way of leasing out an address, but on a short duration such that the client checks back in soon to renew the address and hopefully by then the Connection Interrupted state has transitioned to Normal or Partner Down. This is where the MCLT comes in. The servers lease out an address but not for the typical DHCP lease duration, but only for the MCLT duration.
    • If the request is for an address renewal the standby server can do so but again same rules as above apply. It can’t assume that the partner won’t mark this address as unused any more (as it wouldn’t have received the lease renewal request) and so both servers must renew or assign new addresses for the MCLT duration only as above.

That is not the whole story though! Turns out the MCLT is not just the temporary lease duration. It has one more influence. Check out this MCLT definition from a TechNet article:

The maximum amount of time that one server can extend a lease for a DHCP client beyond the time known by the partner server. The MCLT defines the temporary lease period given by a failover partner server, and also determines the amount of time that a server in a failover relationship will wait in partner down state before assuming control over the entire IP address range.

The MCLT cannot be set to zero, and the default setting is 1 hour.

Note the part in italics. So once a relationship transitions from Normal -> Connection Interrupted -> Partner Down (via manual admin intervention or after the State Switchover Interval) the standby server waits for the MCLT duration before taking over the entire scope. Why so?

The reason for this is because during the Communication Interrupted it is possible the active server might have assigned some IP addresses to clients – i.e. the server wasn’t actually down. These would be assigned with a lease period of MCLT and when this period expires clients will contact the erstwhile active server for a renewal, fail to get a response, and thus send a new broadcast out which will be picked up by the new active server. By waiting for the MCLT duration before taking over the entire scope, the new active server can get all such broadcasts and populate its database with any leases the previous active server might have handed out.

Here’s an excerpt from the DHCP Failover RFC:

The PARTNER-DOWN state exists so that a server can be sure that its partner is, indeed, down. Correct operation while in that state requires (generally) that the server wait the MCLT after anything that happened prior to its transition into PARTNER-DOWN state (or, more accurately, when the other server went down if that is known). Thus, the server MUST wait the MCLT after the partner server went down before allocating any of the partner’s addresses which were available for allocation. In the event the partner was not in communication prior to going down, it might have allocated one or more of its FREE addresses to a DHCP client and been unable to inform the server entering PARTNER-DOWN prior to going down itself. By waiting the MCLT after the time the partner went down, the server in PARTNER-DOWN state ensures that any clients which have a lease on one of the partner’s FREE addresses will either time out or contact the server in PARTNER-DOWN by the time that period ends.

In addition, once a server has made a transition to PARTNER-DOWN state, it MUST NOT reallocate an IP address from one client to another client until the longer of the following two times:

  • The MCLT after the time the partner server went down (see above).
  • An additional MCLT interval after the lease by the original client expires. (Actually, until the maximum client lead time after what it believes to be the lease expiration time of the client.)

Some optimizations exist for this restriction, in that it only applies to leases that were issued BEFORE entering PARTNER-DOWN. Once a server has entered PARTNER-DOWN and it leases out an address, it need not wait this time as long as it has never communicated with the partner since the lease was given out.

Interesting. So the MCLT is 1) the temporary lease duration during a Connection Interrupted state; 2) the amount of time a server will wait in Partner Down state before taking over the entire scope; and 3) the amount of a time a server will wait before assigning the IP address previously assigned to a client by its partner to a new client.

For completeness, here’s the definition of State Switchover Interval from TechNet:

If automatic state transition is enabled, a DHCP server in communication interrupted state will automatically transition to partner down state after a defined period of time. This period of time is defined by the state switchover interval.

A server that loses communication with a partner server transitions into a communication interrupted state. The loss of communication may be due to a network outage or the partner server may have gone offline. By default, since there is no way for the server to detect the reason for loss of communication with its partner, the server will continue to remain in communication interrupted state until the administrator manually changes the state to partner down. However, if you enable automatic state transition, DHCP failover will automatically transition to partner down state when the auto state switchover interval expires. The default value for auto state switchover interval is 60 minutes.

When in Communication Interrupted mode it is possible to mark the relationship as Partner Down manually. This can be done via PowerShell as follows:

Or via MMC, by going to the Failover tab.