Archive for the ‘Desktop Management’ Category

« Older Entries

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

March 28th, 2013 by Paul Opper | No Comments | Filed in Application Packaging, Desktop Management, Microsoft

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! 

 

 

 

Did you like this? Share it:

Tags: , ,

Installing HKCU keys using a Windows Installer repair

March 14th, 2013 by Paul Opper | No Comments | Filed in Application Packaging, Desktop Management, Microsoft

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. 

 

 

Did you like this? Share it:

Tags: , ,

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

August 2nd, 2012 by Paul Opper | No Comments | Filed in Application Packaging, Computer Support, Desktop Management, Desktop OS, Microsoft, Uncategorized, Windows 7

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 HKLM\TempHive 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!

 

Did you like this? Share it:

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

May 10th, 2012 by Paul Opper | 6 Comments | Filed in Computer Support, Desktop Management, Desktop OS, Microsoft, Windows 7

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:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

**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!

 

Did you like this? Share it:

Tags: ,

Remotely Reboot a Bunch of XP Workstations…

April 5th, 2012 by Jeremy Pavlov | 2 Comments | Filed in Computer Support, Desktop Management, Desktop OS, Microsoft, Windows 7

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:\TEMP\RemoteRebooter-Input.txt, and here’s a varied example of how it might look:

pc1
10.2.1.3
wks22.domain.local
192.168.33.44
amyscomputer

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 OFF
@Echo Process RemoteRebooter...
@For /F "tokens=*" %%Q in (c:\temp\RemoteRebooter-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!

 

 

 

Did you like this? Share it:

Tags: , , , , , , , , , , ,

Basic MSI – A Simple Need (Part 1): Delete a Difficult Desktop Icon

March 15th, 2012 by Derek Socall | No Comments | Filed in Application Packaging, Desktop Management, Microsoft

Sometimes it’s necessary to refresh the desktop after certain actions are performed through a MSI.  It may be that the desktop background has changed, or that icons have changed and need to be refreshed, etc. 

Removing a Difficult Desktop Icon

In our particular case (and as is used in the examples in this post), Broadcom’s WIDCOMM Bluetooth Software was installed.  This example customer always removes icons from the start menu and desktop in application installers deployed in the enterprise.  This is where a seemingly simple customization became a challenging one — it’s a good thing that I’m always up for a challenge!

Normally, removing icons from the desktop would require the packager to write a script to delete “.lnk” files from the current user or “AllUsers” profile’s “Desktop” folder.  However, in our scenario, the “My Bluetooth Places” icon is unique in that it cannot be so easily deleted:

My Bluetooth Places

Thanks go out to “Scorps” at the Video Help Forums for demonstrating how to get this done through the Windows registry.  Here are the steps:

  1. Open up the registry editor (Start> Run> regedit)
  2. Browse to the following key:
     
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace\{6af09ec9-b429-11d4-a1fb-0090960218cb}
  3. Delete the entire key {6af09ec9-b429-11d4-a1fb-0090960218cb}!
  4. Refresh the desktop to apply/show the changes.

With that being said, creating a VBScript to delete a registry key is relatively simple:

Option Explicit 
Dim WshShell, regKeyDelete 
Set WshShell=CreateObject("WScript.Shell") 
regKeyDelete="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace\{6af09ec9-b429-11d4-a1fb-0090960218cb}" 
WshShell.RegDelete regKeyDelete

 

Refreshing the desktop, on the other hand, posed to be a challenge!  Stay tuned to Part 2 to see how this task was accomplished…

 

 

Did you like this? Share it:

Tags: , , , , , ,

Windows Installer Verbose Log Analyzer…

March 8th, 2012 by Paul Opper | No Comments | Filed in Application Packaging, Computer Support, Desktop Management, Microsoft, Windows 7

All software packagers know that an installation log file is critical for understanding and analyzing the behavior of an installation package, particularly with Windows Installer .MSI packages.  Many, however, are not aware of a very helpful utility that can be used to help read log files.

Microsoft provides a tool called “Windows Installer Verbose Log Analyzer” with the Windows SDK for Windows 7 and .NET Framework Service Pack 1.  The log analyzer, WiLogUtl.exe, provides a graphical interface that allows you to interact with the log and presents critical installation information in an easy to read format.

 

 

The entire SDK is approximately 1.4 GB; but if you only want to install WiLogUtl.exe, as well as a few other handy utilities like Orca, select only Win32 Development Tools on the Install Options install dialog.  By default the log analyzer is installed to C:\Program Files\Microsoft SDKs\Windows\[version number]\Bin\WiLogUtl.exe.

One particularly handy feature of WiLogUtl.exe is the ability to view a log file in an HTML format.  This special format presents the installer actions in a color coded layout which allows you to easily distinguish errors from custom actions, standard actions and other information in the log.  The interface includes buttons to quickly navigate through the log.

 

Another very useful feature of the log analyzer is the Property button, which allows you to see all the installer properties and – more importantly – their values, in one window.  Often times unexpected installation behavior can be attributed to incorrect property values.

 

 

The States button provides a view of the installation’s features and components; also very handy.

 

Understanding the root cause of unexpected installation behavior and resolving it can help ensure that your package won’t cause problems in production – and the Windows Installer Verbose Setup Log Analyzer can help save time doing it.

 

 

Did you like this? Share it:

Tags: , , , , , , ,

Basic MSI – Public_Property as Component Install Location

February 2nd, 2012 by Derek Socall | No Comments | Filed in Application Packaging, Computer Support, Desktop Management, Desktop OS, Microsoft, Windows 7

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.

Steps:

  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 [PUBLIC_PROPERTY]).
  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!

 

Did you like this? Share it:

Tags: , , , , , , , ,

Application Virtualization – The UAC Panacea?

January 19th, 2012 by Cyndi Meinke | No Comments | Filed in Application Virtualization, Desktop Management, Desktop OS, Managed Desktop, Microsoft, Symantec, Virtual Desktop Technology, Windows 7

…with contributions from Aaron Gierak, Voltaire Toledo, and Jeremy Pavlov.

The User Account Control (UAC) Challenge

It is commonly known that in XP you have to give end users Administrator privileges in order to do even the most simple routine tasks; like changing the system clock, plugging in a USB drive, running a defrag, updating software, or even running security products.  Of course you can use the RunAs command, but that still requires having an Administrator password – which defeats the security purpose of a limited user account.  And just when we thought moving to Windows 7 would eliminate this security privilege nightmare, enter UAC…

User Account Control (UAC) is a technology aimed to improve the security of Microsoft Windows by limiting application software to standard user privileges until an administrator authorizes an increase or elevation.  In this way, only applications trusted by the user may receive administrative privileges, and malware should be kept from compromising the operating system.  In other words, a user account may have Administrator privileges assigned to it, but the applications that the user runs do not inherit those privileges unless they are approved beforehand, or the user explicitly authorizes it.

It is possible to turn off UAC while installing software, and re-enable it at a later time.  However, this is not recommended since File & Registry Virtualization is only active when UAC is turned on – and if UAC is switched off, user settings and configuration files may be installed to an unintended location (i.e. a system directory rather than a user-specific directory).  Also Internet Explorer 7′s “Protected Mode” – whereby the browser runs in a sandbox with lower privileges than the standard user – relies on UAC; and will not function if UAC is disabled.

The Application Virtualization Question

So is application virtualization the solution?  If a virtualized package runs at the kernel level, does it eliminate having to give an XP user Administrator rights?  When you repackage an application that you have been running in XP – in order to port to Win7 – does the app skate by UAC in a way that allows you to keep UAC turned on?

By default, UAC virtualizes requests for protected resources to provide compatibility with applications not developed for UAC.  This is important because many applications written for Windows XP and earlier operating systems assume that the user has administrative privileges and attempt to write to protected resources such as the Program Files or System folders.  The first time an application makes a change to a virtualized resource, Windows copies the folder or registry key to the location within the user’s profile.  Then, the change is made to the user’s copy of that resource.  UAC virtualization is designed to allow already-installed applications to run successfully with standard user privileges, even if they store temporary files or logs in a protected folder.

Installs, Upgrades, and Updates

Many of the problems with UAC come from application installs or upgrades/updates where a new driver or an action that requires UAC acceptance is needed.  With application virtualization – especially a tool like Symantec’s Workspace Streaming where you package from the kernel level – you can bundle the drivers *inside* the virtual app.  As a result, nothing would ever be required of the end-user since nothing is ever “installed”. 

Secondary Executions

However, another issue that bumps against UAC is what we commonly call the “Secondary Execution Event”, where a loaded executable decides to make a call on its own (outside of the one that the app designer intended).  For instance, if a permitted/intended executable launched, and then it calls out to the manufacturer for an updated version, or the latest driver, that is not pre-bundled in the package.  Examples of this are the Juniper VPN agent or the MS Security Center executable.

Panacea or Pariah?

The good news is that application virtualization absolutely does address UAC and elevation features by isolating areas that normally prevent non-elevated users from writing to them by creating a virtual HKLM registry hive, \Windows and \Program Files.  Virtualizing applications also mitigates potential conflicts in a shared session environment like Remote Desktop Servers or XenApp.

However, is application virtualization the silver bullet to fix all elevation and UAC issues?  The answer is “it depends”.  If the application explicitly requires elevated privileges within its manifest, then it will always present a UAC prompt.  In addition, if the application attempts to make a system change like a driver installation or some kind of self-updating feature, it will force Windows 7 to prompt you for elevation.  These challenges can be further addressed with tools such as AppSense Application Manager, or Viewfinity Privilege Management (which elevate a user’s privilege on a per-executable basis), or SystemGuard (which can elevate privileges to write to the registry).

The bottom line is that application virtualization brings many advantages.  In addition to extending the life of legacy applications, reducing deployment costs, and reducing user downtime caused by install/uninstall issues and application conflicts, many UAC issues can be mitigated with application virtualization, especially when coupled with effective use of user virtualization tools.

 

Next installment – Application Streaming…

 

Did you like this? Share it:

Tags: , , , , , , , ,

Logging Windows Installer transactions…

January 5th, 2012 by Paul Opper | No Comments | Filed in Computer Support, Desktop Management, Desktop OS, Microsoft, Windows 7

Building and deploying Windows packages in enterprise deployments can be a challenge when it goes smoothly, but especially difficult when the package deployment hits bumps in the road.  Just when you think you’ve got that application perfectly bundled, tested, and deployed, an unforeseen interaction can knock the legs out from under you.

And of course, the behavior of  Windows Installer itself can be frustrating and may even seem a bit mysterious; making app deployment even more of a challenge.  The installer follows very explicit rules for everything it does, and enforces them rigidly.  Creating a log file for an .MSI installation might just be the saving grace – providing insight when troubleshooting installation errors and other unexpected behavior.

Most application packagers are aware that a verbose log file can be can be generated by passing the parameter /l*v install.log to the Windows Installer engine  (msiexec.exe).  But what about when Windows Installer unexpectedly initiates a “self repair”, or errors occurs during an application uninstall?

Here’s one thing that can help:  There is a registry value that can be set which causes all Windows Installer transactions on a system (installs, uninstalls, repairs, etc.) to be logged to a file.  Just add the following key to the registry:

Warning:  Don’t goof around in the registry if you don’t know what you’re doing.  Seriously.  Don’t.

Registry key: HKLM\Software\Policies\Microsoft\Windows\Installer
Value Name: Logging
Value Data (Reg_SZ): voicewarmup

Note that which temp directory the log file is created in depends on the user account under which the Windows Installer transaction was run.  All the relevant information is logged: custom actions, property states, feature states, and error codes.  These can be very helpful in resolving the issue!

Did you like this? Share it:

Tags: , , , , ,

« Older Entries