Archive for the ‘Desktop OS’ Category

« Older Entries

A cool ‘Remote Desktop Connection Manager’ tip!

April 4th, 2013 by Matthew Sharland | No Comments | Filed in Desktop OS, Microsoft, Virtual Desktop Management, Windows 7, Windows 8, Workstation Management

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:

screenshot

 

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

 

 

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: , , , , , , , , , , ,

Active Setup – Solve Problematic HKCU Keys…

March 29th, 2012 by Aaron Gierak | 1 Comment | Filed in Application Packaging, Desktop OS, Microsoft, Windows 7

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:

HKLM\Software\Microsoft\Active Setup\Installed Components\<UID>

…and also under:

HKCU\Software\Microsoft\Active Setup\Installed 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_MACHINE\SOFTWARE\Microsoft\

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.

 

Did you like this? Share it:

Tags: , , , , , , , ,

Finding Rogue KMS Servers in the Enterprise…

February 9th, 2012 by Jeremy Pavlov | No Comments | Filed in Desktop OS, Linux, Microsoft, Microsoft Infrastructure, Windows 7

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
  }
  else
  {
    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

Enjoy!

:)

 

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: , , , , ,

Symantec Workspace Streaming / Virtualization Overview

May 24th, 2011 by admin | No Comments | Filed in Desktop Management, Desktop OS, Symantec, Symantec Healthcare, Virtual Desktop Management, Virtual Desktop Technology, Virtual Infrastructure, Virtualization

Understanding Workspace Streaming (SWS)

Symantec Workspace Streaming

Symantec Workspace Streaming is an application streaming solution that enables on-demand application provisioning, offline cache, license recovery and instant application upgrades. Symantec Workspace Streaming increases end user productivity with controlled, guaranteed access to any Windows based applications from any location at any time, including remote and mobile users.

Key Features

  • On-demand application streaming – simplifies OS image management by reducing the number and size of images
  • Dynamic license management – proactively insures license compliance by avoiding over-deployment and optimize software costs by re-harvesting licenses when they expire or after a period of disuse
  • Single-click application upgrades – upgrade and patch applications quickly and painlessly, or roll back applications to the previous version if required
  • Disconnected Usage Capability

Key Benefits

  • Reduce software license costs
  • Simplify Application delivery
  • Reduce application support costs/disruption
  • Improve utilization of existing hardware and software resources

 

Symantec Workspace Virtualization

Symantec Workspace Virtualization provides application virtualization that helps reduce application conflicts, testing requirements and support calls. Symantec Workspace Virtualization helps IT organizations improve management and control over endpoints to reduce the total cost of ownership of laptops and desktops.

Key Features

  • Virtual application layers – patented filter driver technology enables virtual layers that are transparent to the base operating system and other applications
  • Selective isolation – provides a solution for incompatible Windows 7 apps and insures system and application compatibility under any circumstance
  • Endpoint Management integration – Workspace Virtualization is a standard component of Symantec’s Client Management Suite (CMS), Total Management Suite (TMS), Symantec Workspace Streaming (SWS), Software Management Solution

Key Benefits

  • Eliminate conflicts between applications and base operating system, such as incompatible Windows 7 applications
  • Reduce application pre-deployment testing requirements
  • Provide instant reset for broken applications

Did you like this? Share it:

Tags: , , , ,

« Older Entries