Ben’s Tech Blog

I re-installed Vista on my laptop a few days ago and since rebuilding I haven’t been able to download the latest version of messenger - It always comes up with “page cannot be displayed”. I tried a lot of different things but still couldn’t download it. In the end I managed to download MSN Messenger 7.5 and then upgrade by logging into my machine as an administrator and logging into MSN messenger. When logging in it asked me if I wanted to upgrade - It then downloaded the latest version successfully. I’m still not sure why I couldn’t download it directly from the webiste but the main thing is that I’ve got it installed now. I thought I’d post this in case it helps anyone else.

When you connect to a resource on another machine and supply a username/password, you are given the option to “save password”. It took me a little while to find where these credentials are stored in Windows XP, so I thought I’d share it with you.

The process is slightly different depending on whether or not the logged on user has local admin rights.

Viewing cached credentials – with Admin rights

Viewing cached credentials – without Admin rights

In either case, you will be presented with the following box that allows you to add, remove or modify cached credentials.

One of the issues that I’ve come across at various times in the past is that you can only authenticate to a machine with a single set of credentials. In other words, if you map a drive to \\server1\share1 as UserA, then you cannot map a drive to \\server1\share2 as UserB. You need to use a single user account that has access to both shares.

A while back we needed users to access resources on a server in an untrusted domain (in other words, there was no trust relationship between the two domains/forests). Because the server was in and untrusted domain, users were prompted for a username and password when they tried to access an application stored on the server. We created a generic account in the destination domain so that users could connect to the server and access the application. However, the server was also a file server, and some users needed to access another share with a specific user account that the generic account didn’t have access to. The problem was that the users had already connected to the server with the generic account and had saved the password. This is where being able to remove the saved credentials came in handy. Once we removed the cached credentials of the generic account, we could then have users connect to the server with the specific account and access both the application and the data share.

As a network admin, I’m often handed software and asked to deploy it for a bunch of users. In a lot of cases the software is provided by a supplier or customer and in some cases is used to connect to their server over the internet. I’m amazed at how much of this software is, in my opinion, poorly written. Here are a few things that make me cringe, and often give me a headache.

Local admin rights

Running as a non-admin is obviously a best practice security measure, but a lot of developers make it difficult to put it into practice. When we went through the process of removing local admin rights from users, we ended up with a fairly long list of software that wouldn’t work without admin rights. To get around this, we used the Sysinternals Regmon and Filemon utilities to find out which registry and file system objects were giving us “access denied” errors. After identifying these, we were able to modify the object’s permissions to give the local users group the required access.

I come across a lot of software that doesn’t work without elevated user privileges, and I often have to go the same process as above to get them to work under an ordinary user account.

No Proxy support

We are running several pieces of software that cannot be natively proxied. By that I mean that they need to connect to servers using ports that are not sent to a proxy server, even if one is specified in IE. Sometimes we are able to get around this by installing the Microsoft Firewall Client (an ISA feature), but at the moment I am testing software for users who are required to use a Squid proxy, and I’m not aware of any equivalent solution.

There have been cases where using the firewall client doesn’t work either, so opening the required ports on the internet firewall is the only option. This is a relatively simple solution if you have a local internet connection, however a lot of companies (like ours) only have internet connections in regional centers which makes it more difficult. In situations where the software is installed in a remote site, we’ve managed to implement a work-around by creating a translation on the local router (for the network that the user belongs to) to convert the public IP address (that the software attempts to connect to), to a private IP address (that belongs in the subnet that the internet firewall resides in). Once that translation is in place, another translation is required on the internet firewall to translate from the private IP address to the original public IP address. Although it’s possible to do this, it’s not ideal, and in our case, involves a third-party (the WAN provider).

Java

It may be a nice development platform, but running multiple java applications can be difficult, particularly when they use different versions of Java. I’m currently testing a desktop environment with 5 different Java applications; only 2 of these applications use the same java version, so there are 4 different versions of Java installed. Java doesn’t seem to be completely backwards compatible, so if an application is developed for Java version 4, it may not work if only Java version 5 is installed on the workstation. In order to get the application to work, you need to install Java version 4. The problem is, to install Java version 4, you first need to uninstall version 5, then install version 4, and then of course install version 5 again so that your other Java app will work. I spent a fair bit of time trying to get all of the Java apps working in harmony. The golden rule it seems is to install the oldest version of java that you require first, followed by the next oldest version and so on. In any case, its a head-ache, so I never like receiving software written for Java.

I’m sure if I thought harder I would be able to list more things that annoy me but these are the three things that have caused me headaches in the last few days.

The windows scripting host (WSH) allows administrators to execute scripts to automate administrative tasks, execute network login scripts and query systems for information - just to name just a few of it’s benefits.  I regularly write and run scripts; in fact I sometimes wonder how I got by before I ventured into the scripting realm.  The problem with the windows scripting host however is that it can be a launch-pad for malicious code.  Some administrators choose to disable the use of WSH on workstations and servers to prevent malicious code from executing.  While this makes a lot of sense from a security standpoint, it severely cripples your ability to automate admin tasks, and if you’re using vbscript based login scripts then you’re going to have a real problem. 

A far better approach is to use software restriction policies to dictate which scripts are permitted to run.  Software restriction polices are a new feature available in Windows Server 2003 and Windows XP that are set via Group Policy.  You’ll find the software restriction policy under Computer Configuration/Windows Settings/Security Settings/Software Restriction Policy. 

Software restriction policies are designed to control the execution of all executables, not just scripts.  There are 4 types of software restriction rules; I’m going to focus on the 3 that are beneficial to locking down the Windows scripting host.  To implement the rules, you simply create them in the Additional Rules folder.  Note that the folder already contains 4 default rules.

Path Rules:

Perhaps the simplest to implement, path rules let you either allow or disallow executables to run based on the path that they are launched from.  For example, you could disallow the execution of .vbs files (and the various extensions associated with script files) but permit those files that are in particular network share to run.

In this Example, you would create the following rules:

You could also use path rules to disallow vbscript files from running but allow them to run from your netlogon shares so that vbscript based login scripts could run:

Note that Microsoft’s recommendation is to avoid using environment variables where possible, as environment variables can be changed by the user to point to a different path.  If you choose not to use the %logonserver% environment variable you may want to consider using your domain controllers’ names instead. This may be cumbersome if you have a large number of DCs, but you do have the ability to use wildcards in path rules, so if all of you domain controllers where named DC1 - DC100 you could implement a policy similar to the following:

I’m comfortable in using the %logonserver% variable, and would be happy to use the first example in a production environment.

Hash Rules:

Hash rules have their advantages, however for locking down WSH they don’t provide too much flexibility.  Using a hash rule, you can allow or disallow the execution of files based on their content.  When you create a hash rule, a “hash” of the file is calculated.  Each time an executable is run, a hash of the file is compared with the hash stored in the policy.  In the case of locking down WSH, you could create a path rule to disallow all vbscript files, and then create a hash rule for each script that you want to allow.  While this may be suitable if you are using a single login script that rarely changes, or if you use only a handful of admin scripts that rarely change, it isn’t ideal for environments where scripts frequently change or like me you write new scripts every week.  The advantage to using hash rules over path rules though is that you can modify the filename and the hash will not change.  You can also run the script from any path;  as long as you don’t change the actual script itself you won’t need to modify the rule.

Example of hash rule to allow approved scripts:

Certificate Rules:

Certificate rules are an excellent way to lock down WSH to only allow approved scripts to run.  With a certificate rule, you import a digital certificate into a rule and then digitally sign each script that you want to approve with the same certificate.  The advantage to using certificate rules over path or hash rules is that the contents, path or filename of the script can change without preventing the approved script from running. 

The downside to using certificate rules is that you either need to purchase a digital certificate from a trusted public CA or install your own CA server and issue a certificate from there.  In both cases, the CA needs to be defined in the ‘Trusted Root Certification Authorities’ on your workstations and servers.

Importing the certificate

Once you have obtained a certificate to sign your scripts, you need to import the certificate into the rule.  This is fairly straight forward, you simply create the rule, then browse to the certificate file (*.cer, *.crt).

Signing Scripts

Strangely enough, you actually need to use a script to signs scripts.  The following is an example of a script that signs the C:\Scripts\script.vbs script with a certificate called Ben Christian.  The certificate must first be imported into the certificate store of the machine that you run the script on.

set objSigner = WScript.CreateObject(”Scripting.Signer”)
objSigner.SignFile “C:\Scripts\script.vbs”, “Ben Christian” 

Like the other rules, to implement a certificate rule to allow signed scripts to run, you would first create path rules to prevent the various script extensions from running.

Example of a certificate rule to allow approved scripts:

Using Certificate rules is probably the most secure way to lock down WSH with software restriction policy.  If certificate rules seem too cumbersome to implement, path rules are a good way to go.  In any case, implementing software restriction policies to lock down WSH on your client and server machines is better than doing nothing, and is an ideal balance between security and convenience.

A good friend of mine, Todd, sent me a link to this document:

Service overview and network port requirements for the Windows Server system 

The first section of the article contains a list of the Windows Server and client services with their corresponding TCP/UDP port numbers, sorted by the service itself.    The Exchange Server and Outlook clients section is quite comprehensive, with related articles regarding the use of static ports and information about RPC over HTTP.

The second part of the article contains a summary table sorted by port number to make it easy to identify which services listen on a particular port.

A valuable article.

There are some awesome utilities that you can download from the Microsoft website. Although there doesn’t seem to be a single download file for all of the utilities, they all fall under the “PowerToys” name. I haven’t downloaded all of them yet, but I’ve played with a few.

Alt+Tab Replacement

This download replaces the standard Alt+Tab dialog with a new one that includes a preview of the application at that you have selected. My only complaint is that it won’t show a preview for applications that are minimized. Despite that limitation, it’s a great enhancement and I’m really happy with it. It has proved to be particularly useful when you have a whole bunch of web pages open and find yourself constantly switching between them.

Open Command Window Here

I’ve used a registry hack to achieve this in the past, but it’s easier to just install this utility instead. This feature adds a menu item to the context menu (right mouse click) of a file system folder. In other words, if you right click on a folder you can select “Open Command Window Here” and it will open a command prompt with the currently selected folder as the current directory.

Virtual Desktop Manager

This utility allows you to use 4 different “virtual desktops”. A virtual desktop in the context of the Virtual Desktop Manager utility is simply a lay-out of program windows. When you install the utility it creates a new toolbar that you can add to the Windows taskbar.

The toolbar allows you to switch between the virtual desktops. The Green button displays all 4 desktops at once to make it easier to select the window layout that you’re after.

There’s a whole bunch of other PowerToys that you can download, including the latest version of TweakUI.

http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx.

This year daylight savings in NSW, Victoria, ACT, Tasmania and SA has been extended to allow for the Commonwealth Games that will be held in Melbourne. Gary forwarded a message to me that he received from Office Watch reporting that there is a hotfix available to prepare machines for the adjusted daylight savings period.

There’s information regarding the issue and the hotfix here:

http://www.microsoft.com/australia/timezone/2005.aspx

The idea is to get the patch applied as soon as possible as Outlook calendar appointments that are created before the patch is installed will be 1 hour out of wack during the extended period. Appointments that are created after the patch is installed will show the correct time. Apparently Outlook does the time zone calculation when the appointment is created which explains why this is the case.

During the Olympic Games in Sydney daylight savings actually started earlier, and I don’t recall having any issues with screwed up calendar appointments. In any case we’ll get this hotfix out to all of our machines in Australia.

I’ve been doing some work for a lady who owns two retail stores. One of the tasks on my list is to implement a decent backup solution for the point of sales systems.

Whenever I plan backups I like to consider the following scenarios:

• Accidental deletion of data or file corruption (’my documents’)
• A complete system failure like a failed HDD or severe OS issue that renders the system unable to boot
• A disaster that destroys the equipment along with the whole site

When I was looking for the right solution for her businesses I wanted to make sure that I covered those scenarios.

I considered hardware first. I decided that an external HDD or entry level NAS box would be the best way to go. The shops are next to each other, so a wireless link to a shared NAS box would work, or I could recommend external hard drives for both POS systems [The POS systems are Windows XP with MYOB Retail Manager]. Maxtor have a Shared Storage Drive that’s essentially a networked external HDD - It’s a single drive so it doesn’t offer RAID0 or RAID1 but the price fits well. The owner has a laptop that she keeps at home that has plenty of HDD space so the plan is to backup to the shared storage drive and then periodically copy the latest backups on to her laptop so that she has an offsite restore point.

Next I put some thought into the actual backup process. I wanted to keep the costs down so I considered the XP backup utility or robocopy to copy the MYOB data and my docs. I also considered using XP’s ASR feature as a complete system restore solution. I’ve tested ASR before and it seemed to work OK but there were several things I wasn’t comfortable with:

• It’s designed to backup Windows systems files and applications. I can’t be sure that it will backup up third-party software. It doesn’t actually backup data (documents).
• It can’t be scheduled.
• You need to create a floppy disk and burn a CD for each ASR image that you create.

Having used early versions of Ghost before (more for deployment than backup mind you), I considered using it take an image of the PC in case an OS rebuild was required in future. I didn’t think however that I would be able to schedule ghost images. In the old days you would have to boot into DOS to take a ghost image. I had heard though that later versions of Ghost can take images while windows is running and that was enough to persuade me to check out the latest version of Ghost - Ghost 10.

I downloaded and read through the ghost manual and was extremely impressed, so I downloaded the Ghost 10 trial and tried it out. It had me sold in an instant, and this is why:

• It can take images while windows is running
• The images (recovery points as they call them) can be scheduled
• A base recovery point can be taken, and then incremental recovery sets can be scheduled. On the machine I tested on I took an image of an 8GB partition and the initial image file was 6GB (using standard compression). That night, the scheduled image (system backup) ran and created a recovery storage point of around 2MB (MB not GB).
• You can browse the recovery points/sets and individual restore files from them directly. By default Ghost creates a recovery point each month and then a recovery set (the incremental backups) each day. This means that you have a complete history of backups that you can restore from. In this respect it’s similar to running VSS on your XP workstation.
• Ghost can delete older recovery points when you meet a threshold so that your destination does not run out of space
• If a complete system failure occurs, you simply boot from the ghost CD which loads NIC drivers and USB/Firewire drivers. You grab the recovery set from the backup destination (network or USB/Firewire drive) and tell it to restore.

Ghost 10 licenses are around $110(AUD) and in my opinion are well worth the investment. The solution that I’ve proposed for the shop owner is to purchase 2 copies of Ghost 10 and a Maxtor shared storage drive to backup each machine to. She can then copy the most recent recovery point to her laptop each week. Although she won’t have daily offsite backups, she will have a fallback if there is a complete disaster. For any other scenario she will have the ability to restore single files easily herself or a restore complete system (with my help - Symantec are still marketing Ghost 10 to more advanced users).

Using Sysinternals’ psexec it’s possible to open a command prompt on your local machine for a remote desktop or server. This can be a real time saver when you need to obtain information or issue a command on a remote machine but don’t want to connect to the machine using a remote desktop connection or remote connection software like VNC or Dameware. For example, if you wanted to check what DNS server a client computer is using you could start the psexec session and then issue the ipconfig /all command. This is much quicker than establishing a remote desktop connection and issuing the command within that session.
To open a remote command line, simply open a command prompt on your local machine and type:

psexec \\remotecomputer cmd.exe

Note that for the command above to work you’ll need psexec.exe in the current directory, or in a directory that is included in the path system environment variable. You’ll also need admin rights on the machine that you’re connecting to. You can specify a username and password by using the -u and -p switches

You can download the whole pstools kit, including psexec for free from www.sysinternals.com.

In short, the JRE doesn’t like the http:// prefix. When entering URLs into the IE proxy bypass list for sites that use the JRE you should enter them without the prefix.

We’re currently deploying Telephony @ Work’s Call Center Anywhere (CCA) at the company that I work for. The CCA client is web based and uses Sun’s JRE version 5. Due to the amount of traffic between the client and the web server I wanted to make sure that we set the client machines to bypass the proxy for the CCA web server.

This seemed pretty straight forward, I added the CCA webserver URL to Internet Explorer’s (IE) bypass proxy list in the format http://ccasername.domain.com. I used a test account that didn’t have proxy access so that I could confirm that it was bypassing the proxy. IE would allow me to access the CCA login page, but when logging in I was prompted to provide credentials for the proxy server. From looking at the prompts, I could tell that it was the JRE that was prompting for the credentials. I checked the proxy settings in the Java control panel applet and confirmed that it was set to use the browser settings. As a test I manually set the proxy with http://ccaservername.domain.com in the bypass list in the JRE control panel applet with no success.

After a bit of head stratching I tried entering the proxy in the format ccaservername.domain.com (without the http:// prefix). I tried the connection again and it worked just fine.