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…

[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

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? 

😉

 

 

 

Installing HKCU keys using a Windows Installer repair, Pt. II

2017-07-27T00:01:04+00:00 March 27th, 2013|Uncategorized|

Previously, in Pt. I of this series, I wrote about how to install HKCU registry keys (which can also be used for installing data anywhere in a user profile).  Now I’ll go into more depth on how to do this using the popular application packaging product Wise Package Studio.

Though Wise Package Studio has been discontinued by Symantec, it’s still quite popular in many packaging environments.  The main tool used for creating and editing Windows Installer projects in Wise Package Studio is the “Windows Installer Editor”, which was previously available alone as “Wise for Windows Installer” (wfwi.exe). 

Most of the packaging work will be done in the “Installation Expert” view, which is a slightly more “user friendly” or “cleaner” project editor.  After creating my new project, I’ll add a couple files to it.  The files I added are Process Explorer (procexp.exe) from “SysInternals” and it’s help file (procexp.chm).  Process Explorer is one of several extremely useful utilities available (free!) in the Sysinternals Suite

 

1.Wise

 

Next, I’ll add an “Advertised” desktop shortcut to “procexp.exe” from the “Shortcuts” page.  By default, when you add a shortcut to point to a file in your installation the “Advertised” check box is marked. 

 

2.Wise

 

Note that “Complete” is listed in the “Current Feature” drop down list.  By default, Wise starts with a feature named “Complete” and puts all files, registry keys, shortcuts, etc. under the “Complete” feature, but we need a “hidden” parent feature.  So, from the Features page “Add” a new feature.  Give it a name, select “<None>” from the Parent drop down list, “Hidden” from the Display drop down, and check the “Required Feature” check box; the rest of the defaults can be left.  After adding the hidden parent feature, I go into the “Complete” feature to select the hidden feature from its “Parent” drop down list. 

 

3.Wise

 

Finally, I add an HKCU registry key to the new hidden feature.  Notice now that I’ve added a new feature, I can select it from the “Current Feature” drop down list from all the pages in Installation Expert. 

 

4.Wise

 

After the project is compiled, the .MSI can be run on any system “per machine” with the “ALLUSERS” value set to ‘1’.  When a new user logs onto the machine and clicks on the advertised shortcut, the HKCU key will be installed by the windows installer repair. 

 Next time, I’ll take a look at implementing self repair using InstallShield.  I hope you found this tutorial enlightening, instructive, and maybe even a little fun.  Well..uh..instructive and enlightening should be good enough! 

 

 

 

Installing HKCU keys using a Windows Installer repair

2017-07-27T00:01:04+00:00 March 13th, 2013|Uncategorized|

One of the more common (and tricky) issues faced when installing an application in the enterprise is how to install user data.  Typically, the application installer is run silently with no user interaction in the “system” context with administrative privileges.  This method is commonly used so that the software can install in the background without disrupting the end users work.  Fortunately, this method works for a majority of software deployments, because the installer does not need to install anything in the “user” context. 

There are situations, however, when an application requires registry keys or some data files installed in the user’s profile prior to the applications first launch.  One common post-installation method used for installing user data is called “Active Setup”; a full explanation of how to implement this method is beyond the scope of this post… and besides… there’s already been a blog post on this topic

A major drawback of the Active Setup method is that any user logged on to the system when the silent installation occurred must log out of their profile and log back in.  The reason is because the mechanism which initiates Active Setup compares a Local Machine registry keys to one in the User’s profile when the user logs on.  A more convenient and functional method (and slicker, I must say) to install data to the user profile in the user context is by initiating a Windows Installer repair. 

By design, Windows Installer initiates “self repair” or “self healing” when an entry point to the installed application is launched.  Typically, the entry point is an “Advertised” shortcut.  When the user clicks on the shortcut, Windows Installer will perform an integrity check to verify all the “key paths” of the installed application are present; if not present, the Windows Installer repair will install any missing component(s) and their key path.  The key path of a component is typically a file or shortcut. 

One  method for installing Current User registry keys post install is to add a top level “Hidden Feature” (note: the feature doesn’t really have to be hidden, but we do this to ensure that whoever runs the install doesn’t have the option not to install it) to the install which contains all the HKCU keys.  Mark the feature as “required” and make it the “Parent” feature to all other features in your MSI.  Move all HKCU keys to the same component in the required feature.  Finally, add an “advertised” to your application to facilitate the repair.  After the application is installed (in the system context), when a user click on the advertised shortcut a self repair will occur to install the components with the missing key paths… IF the key path doesn’t exist.

Ya see…this blog post was partly inspired by a setup I encountered on a customer location which attempted to use this method for installing the required HKCU registry keys.  When I tested the application, it was not behaving as expected.  I looked into the .MSI that installed it and found that everything had been laid out according to the prescribed method detailed above… except… the component key path holding the HKCU keys was actually an HKLM registry key which already existed on my system!  Thus, the self repair would never “kick off”.  When attempting to initiate a controlled Windows Installer repair, you must ensure the component key path is truly unique, or the repair won’t happen. 

I hope you enjoyed this little insight into Windows Installer and find this method to install user data helpful.  This was just a high level overview; next week, I’ll follow up with a more detailed post on how to implement this functionality. 

 

 

A Wrinkle with a Bundled Wireless Driver and DPInst32…

2017-07-27T00:01:04+00:00 February 20th, 2013|Uncategorized|

Fellow Coreteker Scott DeLand and I were recently working on a “QC” for some bundled wireless drivers, for which the customer used DPInst32.exe to install the drivers.  After the wireless driver folder has been installed to C:ExamplePath, DPInst is launched to install that driver.  Here’s what the launch action originally looked like in ZENworks Configuration Manager (ZCM):

Command:
${WinDisk}ExamplePathCompanyWireless DriverDPInst32.exe

Command Line Parameters:
/s /PATH ${WinDisk}ExamplePathCompanyWireless Driver

Working Directory:
${WinDisk}ExamplePathCompanyWireless Driver

There were a few problems with this, though.  For one, all of the installed driver folders had spaces in them.  When spaces are present in the command line parameters for some executables, they will fail without special care… and DPInst is included in this list. 

The other problem was that the install wasn’t creating an OEM file in C:Windowsinf.  When a new driver is installed, it should create a new OEM file with an incremental counter… so if the last OEM file was OEM94.inf, the next driver install will create an OEM file called OEM95.inf.  Scott pointed out that the drivers weren’t creating a new OEM file… were they really working? 

We tested with the command line and found that if we didn’t use quotes around the /PATH parameter and the parameter contained spaces, DPInst would not work.  Now the Command Line Parameters looked like this:

/s /PATH "${WinDisk}ExamplePathCompanyWireless Driver"

But there was still another problem:  On some machines, this action would fail with an exit code of 768 — and on some bundles, a new OEM file wouldn’t be generated.  Exit code 768 occurs when there is already a wireless driver on the machine, which we discovered previously.  We solved the new issue by adding code 768 as a success return code in the launch action, allowing the process to complete.  The other thing that was discovered was that if the driver was of the same type as another already installed driver, it wouldn’t create a new OEM file.

I thought I’d pass this along to see if it might help others!

 

Don’t Rename Vendor-Provided .MSI Files…

2017-07-27T00:01:04+00:00 December 5th, 2012|Uncategorized|

When packaging an application for deployment in the enterprise, you must also identify it’s dependencies — additional software required for the application to successfully install and function.  Often times these dependencies are redistributable run-times for Microsoft Visual Studio.  These redistributables are so common, they are often packaged separately and “chained” to the dependent application.

This method of installing dependencies usually works pretty well; the deployment tool determines whether to install the package, based on it’s previous installation history.  If, however, the dependency was installed outside the deployment tool’s domain — by an application a user downloaded, for example  — you may encounter errors when the dependency is re-run; this could fail your entire application package chain.

Fortunately, many (but not all — always test!) Microsoft redistributables, like “Visual C++ 2008 SP1 Redistributable Package (x86)“,  are authored so that they can install over an existing install — without actually modifying anything or going into “maintenance mode”.  The screen shot below illustrates that the Windows Installer services runs the .MSI package, and verifies that it’s already installed with the same product code, package code, component IDs, etc., and simply exits without modifying the existing install.  This can be a packager’s saving grace in an unpredictable enterprise environment.

 

Wise Compatibility Key

 

Recently, however, I came across an issue with my philosophy of simply letting the redistributable re-run over an existing install. 

A package I had developed started failing.  After checking the logs, I noticed the failure occurred during the install of the dependent runtime  “Visual C++ 2008 SP1 Redistributable Package (x86)”.  The runtime install was exiting with a Windows Installer general failure code of “1603”. 

A look at the detailed installation log shows a more confusing error: “Error 1316.  A network error occurred while attempting to read from the file: C:Userspopper1Desktopvcredist_x86vc_red_x86.msi”.

With some help from my co-worker (Windows Installer guru Urb Bernier) we were able to find the issue: the .MSI that originally installed the Visual C++ runtime was extracted from the vendor’s .EXE bootstrap and…RENAMED!  A grievous offense in the application packaging world!  Well, that may be a bit dramatic, but it certainly violates all “best practices”.  When extracted from the vendor provided setup file “vcredist_x86.exe”, the .MSI is named “vc_red.msi”.  Perhaps the packager may have renamed the file in order to distinguish the 32-bit setup file from the 64-bit setup? 

The error “1316.  A network error occurred while attempting to read from the file: C:Userspopper1Desktopvcredist_x86vc_red_x86.msi” is Windows Installer’s way of saying it can’t access the file in the path; the “cached” path to the .MSI that originally installed the Visual C++ runtime.

You see, the issue is that you can rename the .MSI, install it successfully, re-run it successfully, and uninstall it successfully; provided you do all of these actions using the renamed .MSI.  If, however, the actual vendor install runs on that same machine, whether from the bootstrap .exe or from the extracted .MSI, it will exit with a Windows Installer general error code “1603”.

Packaging applications can sometimes be a frustrating task; because no matter how much forethought and care you put into your package, it can always be thwarted.  To be fair, I guess the same could be said for just about any other job.  

However, I hope this example illustrates why you should not rename vendor provided .MSI files!

 

Interactive Services Detection Dialog Suppression…

2017-07-27T00:01:04+00:00 November 7th, 2012|Uncategorized|

I finally got to the bottom of the “Interactive Services Detection” dialog that appeared when running my SCCM advertisement.  The reason, in hindsight, makes total sense…

I was running my .MSI with a /qb-! switch, which means “display basic modal dialogs to the logged on user when running, but hide the ‘Cancel’ button”.  My SCCM program did not have the “Allow users to interact with this program” check-box marked.  Thus, when the advertisement ran, I would see the Interactive Services Detection dialog appear — because Windows Installer was trying to display the install dialogs to the logged on user.

To suppress the “Interactive Services Detection” dialog (below) that appears when Windows detects a service running as “Session 0” (that’s a zero) user…

 

…Simply mark the “Allow users to interact with this program” check-box under Run Mode on the “Environment” tab of your program.

 

 

And that should do it!  Thanks to fellow Coreteker Voltaire for suggesting that I look at this program setting…

Troubleshooting the Interactive Services Detection can be challenging.  Unfortunately, if you are working in an enterprise environment that is still deploying legacy applications, you are likely to encounter it.  So if you are deploying an .MSI through SCCM and you are not running it silently (with a “/qn” switch), be sure to mark the “Allow users to interact with this program” check-box.

 

 

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!

 

Thinking Outside The Bundle…

2017-07-27T00:01:07+00:00 June 6th, 2012|Uncategorized|

Once you’ve honed your packaging skills, and created some cool application bundles; you’re not done yet.
 
Having a great bundle installation without the ability to cleanly remove that bundle is like having a powerful engine in a motorcycle… with no brakes.  Oh sure; it’s great as long as you’re going forward, but if you need to stop and make changes (for example, if you have to change enterprise mail system clients), you just might have no choice but to re-image every motorcycle.  Okay, that’s where the metaphor breaks down a bit, but you get my point.
 
Anyway, here are a couple issues that I see as important that — if left unattended — could really grow into larger problems.
 
The bundle “Uninstall” – one should put as much effort in testing and implementing “best practices” for the bundle UNinstall as we do for the install.  By default, a bundle’s uninstall actions are simply the Install actions in reverse; this is OK for simple bundles, like a bundle that installs only one .MSI.  However, many bundles are more complex.  Ensuring your bundle uninstalls without error is also important.
 
I disable the default “Uninstall” action for most of my bundles and add custom uninstall actions to avoid errors, especially for bundles that install dependent bundles (I generally leave dependent bundles installed).  This leads me to…
 
Dependent bundles – I think most packagers are aware that it is a best practice to determine an application’s dependencies and, whenever possible, bundle the dependencies as standalone bundles to allow the software deployment/management system (for example, ZCM) to manage them.  This will reduce errors when an application attempts to install a package that is already installed or uninstall a shared dependency; it also saves time.
 
If you keep these things in mind, you can get on your bad motorbundle and ride…  and stop when you want…
🙂
 
 

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:

HKEY_LOCAL_MACHINESOFTWAREMicrosoft

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.

 

Load More Posts