XP EOS D-9… And Counting…

2017-07-27T00:01:02+00:00 March 30th, 2014|Uncategorized|

It’s Monday.  The last day of March.  Forget the fact that tomorrow is April Fool’s Day.  The Windows XP “End of Service” date is now only 9 days away! 

Before reading on, it might be a good idea to reference my post from last month, “XP Elimination — The looming crush…” and “XP EOS M-9… And Counting…

Now that you’ve caught up on those previous articles, let’s spend a moment catching up on our 3 semi-fictitious companies and see how they are doing.

Organization “A” – What, me worry?

For our fictitious Organization “A”, things are actually getting better – at a price, that is.  You see, they realized they had no hope of making the deadline, and decided to throw buckets of money at the problem.  They brought in consultants, vendors, and staff leaders, and locked them in a room with a blank checkbook.  The 20,000 XP machines are rapidly becoming 7000 or so machines and dropping.  It’s “getting done”, but in a very “machine gun” style that doesn’t lend itself well to on-going management or future enhancements and upgrades.  This just means that after this checkbook is empty, they’ll be setting up for Round 2, in preparation for the next generation.  If they had gotten underway earlier, they could have had at least *some* of the tools and infrastructure in place to carry forward…  But, no…

Organization “B” – Nope.  We don’t wanna.

Well, Organization “B” is now partially integrated into Organization “C”.  They’re not going to make the deadline, I’m afraid; but because Organization “C” is so ruthlessly efficient, they are at least documenting the environment, planning the on-going integration, and actually deploying some elements of the extended infrastructure.  They still have most of the 40,000 XP workstations to get to, but the future looks better.  They’ve got fingers crossed that no calamity will befall them over the next few months as they catch up, and they are considering an alternate (expensive) support strategy.  It’s about the best they can do, given their previous situation.

Organization “C” – The best-laid plans…

For the original Organization “C” side of the C/B acquisition, things actually look pretty good.  Across the infrastructure, there are still a few thousand XP machines – but most of these are documented and/or isolated, or about to be replaced shortly.  It’s down to the wire!  But we can finally say that they’ve booked their project completion dinner party reservations.  Congratulations!  But keep at it with Organization B… 

Organization “D” – Yeah?  So?

Since my last post, I met Organization “D”.   Nice folks; smart too.  But they simply cannot afford to care about the deadline.   After a string of financial hardships, org changes, and so forth, they are only now making enough headway to think they’ll survive.  As a result of the hard past, they are only now putting their heads up for air and exploring option of how to get them from “here” to “there”.  They are numb from the scars of the economy, and they don’t see this XP EOS challenge any differently than the past challenges; they will run headlong into it, and take the blows.  They will come out the other end, but only with more scars.

Honestly, some of these stories are heartbreaking, while others are inspiring.  And mind you, I worked through the 2000 bubble like many of you, so you’d think I’d be less moved by the trials that these folks are going though.  But this one is different.  It didn’t make the news the same way (at least in the build-up), but it hits real folks where it hurts.  And we at Coretek are doing our absolute best to help those that we can, as quickly and effeciently — and as prudently — as we can. 

So good luck, hang in there, and we’ll all be watching the clock tick down to the final day.  And we’ll see you on the other side of the XP EOS…


XP EOS M-9… And Counting…

2017-07-27T00:01:03+00:00 July 17th, 2013|Uncategorized|

The Windows XP “End of Service” date is now only 9 months away!  Well, we’re actually just beyond 9-month mark now, but you get the point.

Before reading on, it might be a good idea to reference my post from last month, “XP Elimination — The looming crush…

If you think it’s ridiculous or hilarious that anyone should be concerned about migrating off of XP at this point, then you probably work in a small-to-medium sized company.  You might even be able to consider upgrading all the workstations by yourself (or with a buddy), or maybe you’ve just replaced all the computers with modern devices with updated OS’s.  Easy-peasy.

But many *large* enterprise company/organizations are watching the clock (or should be) for that looming April 8th deadline, for a variety of reasons.  And this is what I really wanted to touch on today — the fact that steering the massive enterprise can be like steering the largest ship in an ocean, but there are other factors to consider in the metaphorical ocean as well.  Like icebergs…  Like other, older ships that require rescuing… 

Okay, I’ve worn out the metaphor, so let’s start discussing some specifics.  Let’s look at the examples of three, ahem, *fictitious* example large organizations that have arrived at three different XP situations.

Organization “A” – What, me worry?

For our fictitious Organization “A”, things are smooth sailing.  Or so they think.  They’ve got only 20,000 XP machines, and they’ve set up a test pilot bed of about 50 Windows 7 machines, and it’s going well.  Well, *that* part’s going well.  What they will soon realize is that their back-end infrastructure isn’t prepared (in design nor scale) for the type of load that their Win7 deployment strategy calls for — and they have only just begun to prepare their applications for re-packaging.  But they aren’t worried.  Well, not as much as they should be, anyway.

Organization “B” –  Nope.  We don’t wanna.

Organization “B” doesn’t have a plan.  It’s not that they don’t have a clue, it’s just that they mostly don’t care.  They have 40,000 workstations, a bunch of old servers, and so on, in a complicated, aging infrastructure.  You see, things don’t really look good for the business end of the company in this age of consolidation, and most folks think they’ll be acquired anyway.  So XP is fine for now.  I guess.  Whatever.

Organization “C” – The best-laid plans…

For Organization “C”, they really have been doing it right.  They jumped in front of the project, and designed/prepared/deployed a sturdy, modern back-end infrastructure.  They rallied the troops and started the application re-packaging very early-on and devised a “just-in-time” strategy to manage application-to-user/workstation tracking and roll out the workstations right behind the infrastructure and apps.  The working schedule seems to indicate that all of their 50,000 workstations should be upgraded/re-deployed right around the the April 8th deadline.  Whew!  It looks like they’re going to make it!  Until…  Uh-oh…  Did we mention that Organization “C” just acquired Organization “B”? 

While these are hypothetical scenarios, I will be re-visiting these imaginary companies over the next few months as we approach the XP EOS date, discussing some of the finer points of their challenges along the way…  Let’s wish them all luck, shall we? 





Publishing MS Word Viewer through Citrix XenApp 6.5…

2017-07-27T00:01:03+00:00 June 19th, 2013|Uncategorized|

Recently, I moved over to the Coretek virtualization team.  It’s a great opportunity to work with new technologies and implement them as part of our Virtual Clinical Workstation solution.  

Citrix is one of the technologies that plays a major part in the solution.  As part of a virtualization implementation we are working on, I was tasked with publishing the Microsoft Office viewers through Citrix XenApp 6.5.  Now, I have a pretty extensive background in software installation and configuration on Windows desktops; however, publishing them through Citrix was new to me.  

The way a published application’s files and registry keys interact with a desktop operating system are fundamentally different.  Therefore, I was surprised to find when I attempted to open a Word document in the published Word viewer by double clicking on the .doc file — the file itself would not open, but the Word viewer would only open up an “Open” dialog.



So, being pretty new to Citrix — and given that it’s a pretty complex application that is comprised of multiple policies, application configurations, and settings, which can redirect content and drive mappings — troubleshooting issues like this can be challenging (and of course, you must also consider all the AD policies applied as well).  In the end, the solution to this particular issue was pretty simple…

Fortunately, once I was able to rule out that content redirection or drive mappings might be the cause, I found a Citrix KB article that addressed the exact issue I was having.  You can read the article here: http://support.citrix.com/article/CTX128151

In short, I had to add a special parameter (“%**”) at the end of the Word Viewer’s Command Line in the Citrix AppCenter (where published applications are stored).  The default parameter contains only one asterisk (“%*”). 




Hopefully this tip will help if you experience the same issue!




A cool ‘Remote Desktop Connection Manager’ tip!

2017-07-27T00:01:04+00:00 April 3rd, 2013|Uncategorized|

I am constantly monitoring multiple Microsoft Windows Servers and XP workstations via Remote Desktop Connection Manager and having to switch between each console one at a time is a very user-intensive and time-consuming process.  Though, I have recently discovered a very useful and time-saving trick that I will share with you below…

First, by default, the Remote Desktop Connection Manager gives you a thumbnail view of all of your workstations when you click on any “group” of servers from the left server pane list.  I always thought this was a “gimmick” and never thought twice about using it for anything because the dimensions of the thumbnail views of the remote desktops were just way too small to be useful.

But after reviewing the program’s options I found that you can modify the size of the thumbnails (Tools > Options > Client Area > Thumbnail Size)!

But that isn’t all!

The thumbnails are actual “live” clickable Remote Desktop sessions; so if you set the pixel size of the thumbnails to 25%, 30% or 40% of your screen size, you can fit 4-12 active server connections into one very productive window (obviously depending on your monitor size and screen resolution!).  This screen cap should give you a good idea of what I mean:



I hope you find this tip as useful as I did!  Enjoy!



How to import the HKCU values of a different profile into your registry…

2012-08-01T23:01:31+00:00 August 1st, 2012|Uncategorized|

When troubleshooting an application installation issue — or an issue with the application itself — on the Windows operating system, it’s often necessary to view the registry.  The Windows registry holds a wealth of information and settings that determine just about everything related to how Windows operates; what it looks like, where and what users can access, and how applications behave.  If you know where to look, or what you’re looking for, this can be a pretty easy task; the “Find” function in the Registry Editor works pretty well.  However, if the issue is with registry keys under the HKEY_CURRENT_USER (HKCU) hive, it can be a challenge.  You see, the keys under the HKCU hive are unique to each users profile; thus, when you view the registry keys under HKCU in the Registry Editor, you are viewing the keys of the current logged-in user profile.

In an enterprise environment, applications are typically distributed via a configuration/distribution system such as Novell ZENworks Configuration Mannager (ZCM) or Microsoft System Center Configuration Manager (SCCM).  When software is installed through these systems, the application installers can be configured to run as the logged on user, under the system profile, or even as a “dynamic” administrator.  If the installer writes values to the HKCU profile they are written to the profile that ran the installer.  Thus, there is often need to view the HKCU values of a different user profile.  Adding more complexity to this, you may find yourself in a situation where the user profile under which the HKCU values are located doesn’t have access to the Registry Editor.  In this situation, you need to import the profile’s HKCU hive into your registry so you can view it.

The HKCU values for a profile are stored in a file called ntuser.dat, located in the root of the users’ profile.  On Windows 7 the path is c:users(profile)ntuser.dat.  There are a few ways to import the ntuser.dat into the registry with Registry Editor, but the quickest and easiest way I’ve found to do this is using the following command from an elevated command prompt:

reg.exe load HKLMTempHive c:users(profile)ntuser.dat

Now the HKCU values of the profile you imported can be viewed under a key called “TempHive” in the HKEY_LOCAL_MACHINE hive.

Hopefully, this will help you to resolve that issue you’re looking into!


How to run bginfo.exe at startup on Windows Server 2008 R2

2017-07-27T00:01:07+00:00 May 9th, 2012|Uncategorized|

No matter what area of IT you work in, there’s always some important piece of information you frequently need to retrieve from a workstation or server; often, it’s several pieces of information.  A lot of time can be spent searching a system to obtain that info. Fortunately, there’s a tool that’s been around for years that can display system info right on the desktop: bginfo (http://technet.microsoft.com/en-us/sysinternals/bb897557).


Bginfo is often a necessity in a lab environment, but it can be used anywhere.  Some of the most popular information to display is:

  • OS version
  • SP version
  • IP address
  • Boot time
  • Disk “Free Space”

…but there’s a whole lot more.  In fact, you can configure bginfo to display just about any attribute of the system.  (NOTE: A detailed explanation about how to display custom info using bginfo is beyond the scope of this article; but if you would like to learn more, check out Shay Levy’s article here: http://blogs.microsoft.co.il/blogs/scriptfanatic/archive/2008/07/22/bginfo-custom-information.aspx).

It’s nice to run bginfo at startup silently and unattended.  This can be challenging, though, particularly on Windows Server 2008 R2.  To do so, you need to edit the following registry key:


**Credit to James from redkitten.co.uk for documenting this here: http://www.redkitten.co.uk/windows-server/using-bginfo-on-windows-server-2008/

Create a new REG_SZ value under the “Run” key named “bginfo”, or whatever you want.  The value of the key will be the path to bginfo.exe, and any parameters you want to pass.  Personally, I’ve had the best luck passing /silent /accepteula /timer:0 to run bginfo silently at startup.  The help file indicates /NOLICPROMPT is also a parameter to bypass the Sysinternals accept EULA dialog, but /accepteula always works for me.

Something else to be aware of — especially if you intend to run bginfo in an enterprise with UAC turned on and GPOs applied — is to keep the output bitmap file in a location that the logged on user has write permissions.  The reason for this is that bginfo runs in the user context to display on the user’s desktop; and because the information is “dynamic” — at least at each user logon — the output bitmap file needs to be updated.  You can change where bginfo stores the .bmp under the Bitmap -> Location… menu.  The default location is in the user’s TEMP directory, which should be okay.

 Bginfo is a fun, easy and very useful way to customize your desktop, and I hope this helps you (and other users) be more productive!


Remotely Reboot a Bunch of XP Workstations…

2012-04-04T22:46:33+00:00 April 4th, 2012|Uncategorized|

I got an interesting question from a co-worker today (we’ll call him “Ray” to protect his identity).  Ray wanted to know if it’s possible for his customer to reboot a bunch of workstations at once, in a way other than the customer’s workstation management system. 

The customer is in the midst of a major migration from XP to Windows 7, and simultaneously from Novell ZENworks 7 to Novell ZCM 11.  Ray’s team has put together an amazing set of automatic deployment steps that take the ZENworks-controlled XP machine all the way to a completely-deployed, domain-managed, ZCM-controlled Win 7 machine with all needed applications installed, via a method called “Zero Touch Deployment”.   And it all kicks off with a reboot — but the only problem is that the bundled reboot in the old ZENworks is not always reliable.

Note: This particular customer’s machines are XP, all in one domain, all are resolvable (either via WINS or DNS), and can all be managed by a single set of credentials; allowing remote administrative execution and permitting the following to work.

So when Ray asked the question, I said, “Absolutely!”  I can do that, and not even break out PowerShell (or bash, for that matter).  Ray had nothing more than a list of computer names, but that is all we need.  Let’s do it old-school, with a DOS batch “for” loop.  Man, I love my job… 

First, the input file; it is just a single list of computer names or IP addresses, one-per-line, in a TXT file.  We put them in a file called C:TEMPRemoteRebooter-Input.txt, and here’s a varied example of how it might look:


The script is a bit on the simple side, but does the job.  I call this RemoteRebooter.bat, and notice that it calls the other input file by name:

@Echo Process RemoteRebooter...
@For /F "tokens=*" %%Q in (c:tempRemoteRebooter-Input.txt) Do @(
1>&2 ECHO Rebooting: %%Q
shutdown -m \%%Q -r -f -t 20 -c "Rebooting in 20 seconds via %0 -- please save your work quickly."
1>&2 type nul
@ECHO Complete!

If you need details on the shutdown flags, type shutdown /? into a command prompt.  And I’m not sure if I should mention it here, but if you want this to work on Windows 7, you have to change the syntax a bit, flipping hyphens (-) to slashes (/).  And of course, this is only one way of doing it, and I know you all have others. 

Make sure to drop a comment and tell us how *you* do it!




Active Setup – Solve Problematic HKCU Keys…

2017-07-27T00:01:07+00:00 March 28th, 2012|Uncategorized|

Hello fellow packagers — ever have an issue with trying to get a program to lay down the HKEY_CURRENT_USER (HKCU) keys?  Well, let’s break down how to fix this issue.  I am going to show you how to set up Active Setup within your applications MSI/MST file in order to have this HKCU stay on the machine, no matter how many users log into the system. 

Active Setup helps to lay down Current User data when an application is deployed or even installed straight from the MSI itself.  Active Setup can be set to do a repair and check for the current user keys that the application needs in order to fully run right.  I am going to show this process, as its one of the most common processes to use with Active Setup.

Windows has keys that it will look for before it kicks off the full install of the MSI.  These keys can be found under:

HKLMSoftwareMicrosoftActive SetupInstalled Components<UID>

…and also under:

HKCUSoftwareMicrosoftActive SetupInstalled Components<UID>

The <UID> should be unique, based off the application you’re using.  Now, the best value to use for the <UID> would be the Globally Unique IDentifier (GUID); I suggest using the Product Code for the GUID.  There are many options you can use for the GUID, but for this example I am going to use the Product Code for the application.  This Code can be found in AdminStudio in a few locations: General Information, Property Manager or Direct Editor->Property table (these locations might be a little different depending on your packaging tool).  Most packaging tools will still have a Property table where you can find the Product Code.  Make sure to write down the GUID you will be using, as we will need this information later on.

So let’s take a deeper look into this process, in order to make these keys no longer an issue.  Let’s begin by opening the MSI we would like to edit.  You can also use a MST transform file if you are working with a vendor MSI.   

Once the application is open you will want to navigate to the Registry section of your MSI/MST.  When you are in the Registry section of your MSI/MST, navigate to:


Under the Microsoft folder, right click the folder and select New and make a new Key, in order to make a new folder under Microsoft.  We will label this folder “Active Setup”.

You might be saying “Hey, I don’t have a Software folder under HKLM”…  This is fine, it just means we need to make one.  It’s easy as pie; you would make the parent folders the same way we did with the “Active Setup” Folder.  Just make sure you build the folder structure as indicated above.

We need to set up two more folders the same way we did with our “Active Setup” folder.  This time, however, we will name the first folder “Installed Components”, under the “Active Setup” folder.  Under the new “Installed Components” folder, make another folder and label it “ProductCode”.

Once we have all our folders set up we need to make a “New string Value” under our “ProductCode” folder.  To do this you can right click on the “ProductCode” folder and you will see the option “New string Value” under the drop down list.  We are going to label our “New string Value” as “StubPath” (Windows will run anything under the “StubPath” whenever there is a command under it).  If the current user key is already on the system, msiexec will not run the repair again because the key is already in the location it should be.

When you have your “StubPath” string created, double click it; we need to make some changes to the values in this string.  You will see the Edit Data box come up; in this box we are going to use the following commands in the Value Data field:

Msiexec /fu (ProductCode or GUID) /qn

These are what the switches are doing that you are adding to the msiexec:

/f – Repair
 /u – all required user-specific registry entries
 /qn – Silent mode with no UI.

 (For other repair options and switches I have added a link to Microsoft’s “msiexec” page:  http://technet.microsoft.com/en-us/library/cc759262%28v=ws.10%29.aspx)

This new key will run once the application is launched.  Make sure to test your application out, and check those keys you have made.  The best way to check the MSI/MST is to launch the MSI/MST though the command line. 

I hope this helps to clear up and issues with Current User key, and gives you a better understanding on how to fix the issue.


Finding Rogue KMS Servers in the Enterprise…

2017-07-27T00:01:08+00:00 February 8th, 2012|Uncategorized|

In larger Enterprises with Microsoft-based infrastructure, it’s highly likely that the licensing for the Windows 7 workstations will be based on the Microsoft KMS model.  If you don’t already know, this means you run servers in-house that register themselves into DNS as license providers, and Windows clients will learn of them (and become affiliated with them) to get a license, rather than contacting Microsoft themselves across the Internet.

Unfortunately, one problem that can occur is that someone who has access to the Microsoft license codes (like an I.T. worker, developer, etc.) might accidentally install a KMS license on a server that is not intended to be a KMS server.  And when a KMS license is installed, the server doesn’t know any better; and dutifully registers its KMS capability with the internal Active Directory based DNS as a VLMCS SRV record. 

Recently, I ran into a situation where I needed to hunt down and eliminate some accidentally rogue KMS servers that had cropped up across a large infrastructure, and be able to re-check at regular intervals.  While I originally wrote the script as a bash shell script for Linux, I re-wrote it into PowerShell recently for someone who asked, and I thought I’d post the new version here.

Mind you, this is a stripped-down version of the script, but it includes all that is needed to run the check manually for a hierarchical DNS infrastructure (although you may wish to strip out components if you just want to check the parent domain). 

Copy the contents below, paste them into a PowerShell script file (*.ps1), change the variables at the top… and have fun!


# Change the following 3 variables as needed.
# This script will loop through the subdomains, checking for KMS servers in each
# subdomain, and then at the parent domain.
$subs = @("subdomain1", "subdomain2", "etcetera")
$parentdomain = mydomain.local
$outfile = "checkKMS-Results.txt"
write "KMS check report..." | Out-File $outfile
write " " | Out-File $outfile -append
write "The only valid KMS servers are at the $parentdomain, as follows:" | Out-File $outfile -append
write "KMS1, KMS2, KMS3" | Out-File $outfile -append
write " " | Out-File $outfile -append
write "There should not be a KMS server at any of these locations:" | Out-File $outfile -append
foreach ($item in $subs)
  write "Checking subdomain: $item"
  $result = nslookup -type=srv _vlmcs._tcp.$item.$parentdomain. |findstr /C:"_vlmcs" /C:"svr hostname"
  if ("X$result" -eq "X")
    write "No registered KMS server in $item" | Out-File $outfile -append
    write "***KMS FOUND at this location: ***" | Out-File $outfile -append
    write $result | Out-File $outfile -append
write " "  | Out-File $outfile -append
write "On the contrary, the following should be valid KMS servers:" | Out-File $outfile -append
$result = nslookup -type=srv _vlmcs._tcp.$parentdomain. |findstr /C:"_vlmcs" /C:"svr hostname"
$result | Out-File $outfile -append
write "...Done!" | Out-File $outfile -append




Basic MSI – Public_Property as Component Install Location

2017-07-27T00:01:08+00:00 February 1st, 2012|Uncategorized|

Sometimes enterprise level packaging can be quite complex, having requirements for variables, sources, destinations, etc., that are all over the map — and all over the network. 

For instance, what if you are working with application bundle files in an MSI that are not intended to be local to the device?  In that case, how does one use a “public property” that contains a path to a network drive as the destination for files to be installed in a basic MSI?

Well, that leads us to this item from Kathy at the Flexera Community Forum:

“If you’re installing the file through a component, you can use a type 35 custom action sequenced after CostFinalize to set the destination folder for the component to the value in the property.”

This translates to using a “Set Directory” custom action.


  1. Create a new component.
  2. Under the new component, create a folder under a location that will always exist (such as under the INSTALLDIR/TARGETDIR location).
  3. Add any files needing to be installed to said folder.
  4. Create a public property with the full destination path as its value (where you want the files to end up eventually).
  5. Create a “Set Directory” custom action.
  6. Source of the CA is the directory created in Step 2.
  7. Target of the CA is the public property created in Step 4 (inputted as
  8. Leave the rest of the CA choices as the default options aside from the “Install Execute Sequence”.   Change the setting to “After CostFinalize”. 
  9. Complete the CA with default options.

The public property can be populated through many different means (a VBS, command-line, etc.) making it quite flexible.  The files will install to the location specified in the public property!


Load More Posts