About Paul.Opper

This author has not yet filled in any details.
So far Paul.Opper has created 13 blog entries.

Using Powershell to check password properties…

2017-07-27T00:01:02+00:00 December 5th, 2013|Uncategorized|

Thanks to Mike Driest, who did most of the testing and documentation on this issue…

One of the many benefits of Coretek’s Virtual Clinical Workstation (VCW) solution is the ability to allow users to run their clinical applications through a “thin” client.  A thin client is a small, lightweight computer that contains very little hardware; just the minimum to allow them to connect to more high powered servers on which their applications run.  

Some of these thin clients run a smaller, “lighter” version of  Windows called Windows “Embedded”, while others don’t run Windows at all!  These devices — while being very inexpensive and convenient due to their small footprint (space wise and energy wise) — pose certain technical challenges in a Windows environment.  One such challenge is the ability to change a user’s Active Directory domain password.

We had to do some troubleshooting recently in our lab to determine whether we had the correct settings to allow an Imprivata “service” account to facilitate a domain user password change from a “zero” client – a device that does not run any form of Windows.  As part of our testing, we had to ensure that the test account’s password was expired; to do this in a timely manner, we set the “pwdLastSet” attribute of the test account to ’0′ (zero):

To confirm that the password was indeed expired we used the following PowerShell command (requires the AD DS PowerShell Snap-In)

“Get-ADUser SamAccountName -Properties *”

You’ll see “PasswordExpired: True” and “PasswordLastSet” is blank. 

Before: 

 

After:

 

 I hope you find this tip helpful!

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.

 

1.BrowseDialog

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 (“%*”). 

 

2.Location.Command.Line

 

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

 

 

 

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. 

 

 

Powershell: Script to Easily Find Objects in the SCCM Console

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

Recently, I had a need to delete an SCCM advertisement in the SCCM 2007 R2 console, in order to ensure it didn’t run on any of my test machines.  Now, I knew that it wouldn’t run, because it was not being advertised to any collections of which my test machine was a member.  But the advertisement was only a test, and I was trying to clean up after myself.

According to Microsoft (link: http://technet.microsoft.com/en-us/library/bb693527.aspx), the way to delete an advertisement from the SCCM console is to drill down through the console (System Center Configuration Manager / Site Database / Computer Management / Software Distribution / Advertisements) and right-click -> Delete the advertisement.  Normally, this is a pretty straightforward procedure…  IF you know where your advertisement is located.

You see, the SCCM console in which I was working divided the advertisements into sub folders based on the Publishers name, and I could not find a folder for the Advertisement I was trying to delete.

 Consol.Advertisements

 

Furthermore, subdividing the Advertisements as such also rendered the “Look For” search field in the console pretty useless; I would have to “Look For” my advertisement in every folder!

SCCM reports can be pretty helpful, and I was able to run a report that gave me just about every piece of data about the advertisement I wanted to delete – except the path to it; the information critical for deleting the advertisement.

A quick Google search led me to this link: http://blog.tyang.org/2011/05/20/powershell-script-to-locate-sccm-objects-in-sccm-console/.  Here, I found the Powershell script that helped me find my elusive advertisement.

The only inputs for this powerful and very useful script are the name of your SCCM site server, and the SCCM object ID, which can easily be found through the “All Advertisements” report in SCCM.  As it turns out, the folder that contained my advertisement had been accidentally moved under another folder. 

It’s great when you find the perfect tool for the job, as I did in this case.  I hope you find it as useful as I did. I intend to keep this one around for future use. 

Thanks, Tao!

 

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.

 

 

Summer Community Project

2012-08-08T23:42:07+00:00 August 8th, 2012|Uncategorized|

Recently about 40 Coretek employees, their friends, and family members, got together to help a family in need.  The family’s home had fallen into disrepair; serious health issues prevented them from being able to keep up with much-needed repairs and yard work. 

We assembled on a Saturday morning with our tools, work gloves, and supplies, to help out.  Braving the heat, humidity, and bugs, we helped to transform the place.  Some of the major jobs we were able to tackled:

– Installed a new back door for the house
– Cleared overgrown weeds, trees and grass
– Tilled the garden
– Painted the house and garage
– Power washed the vinyl siding
– Pruned several tree branches
– Dispose of refuse, like old shingles and garbage cans
– Spruced up flowerbeds with new mulch (lots of mulch!) and edging

…and other work items are still to come…

They say nothing worth doing is easy.  This project wasn’t easy, but it helped some folks that really needed it, and lifted the spirits of everyone involved.  I think we were all proud about what was accomplished; I know I am.

 

 

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…
🙂
 
 
Load More Posts

Fatal error: Uncaught exception 'GuzzleHttp\Exception\ClientException' with message 'Client error: `POST https://dc.services.visualstudio.com/v2/track` resulted in a `400 Invalid instrumentation key` response: {"itemsReceived":1,"itemsAccepted":0,"errors":[{"index":0,"statusCode":400,"message":"Invalid instrumentation key"}]} ' in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113 Stack trace: #0 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Middleware.php(66): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response)) #1 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response)) #2 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(156): GuzzleHttp\Promi in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 113