Nefaria.com

So the other day I was trying to connect to one of the terminal servers that I manage (for the purpose of this post, we’ll call the server ‘TERMSVR01′) and I got the following error message and was promptly disconnected:

At first glance, this seems as though the server ran out of TS CALS (Terminal Server Client Access Licenses). I was pretty sure that the server was configured to use the “Per User” licensing mode. However, a Windows Server 2003 Terminal Server operating in the “Per User” licensing mode can’t run out of licenses to the extent that it prevents the user from connecting (and instead, giving them the aforementioned error message). To the best of my knowledge, it can only do this when it is operating in “Per Device” mode. So this was the assumption that I ran with — that somehow, this server was never configured for “Per User” -or- it was, but the setting was either changed, reset, or corrupted somehow.

So, even though I wasn’t able to connect to TERMSVR01 via Remote Desktop, I was able to “Manage” it remotely by doing the following:

1. Open “Active Directory Users and Computers” on any Domain Controller
2. Expand the “Computers” node
3. Right-click TERMSVR01 and select ‘Manage’

Now we can do a few things (not many) on the server. One thing I wanted was to have a look at the Event Viewer. There were a few error messages like the following:

The more of these I saw, the more confident I was that my assumption was correct — the server was operating in “Per Device” mode and it had finally run out of licenses. I had the following options:

1. Wait for someone to go onsite and reconfigure the licensing mode (easy, but it would have to wait until tomorrow) or…
2. Attempt to reconfigure this setting and restart the service remotely (so that the setting takes takes effect) … all without having “Remote Desktop” access to the server.

Care to guess which option I chose?

Step #1: Override the licensing mode setting using group policy

1. Click ‘Start’
2. Click ‘Run’
3. Type the following command:
   gpedit.msc /gpcomputer:TERMSVR01
4. Click ‘OK’

Those four steps open the group policy (remotely) for TERMSVR01. Next we need to actually change the setting:

1. In the left-hand panel, expand “Administrative Templates”
2. Expand “Windows Components”
3. Click on “Terminal Services”
4. Locate the following setting in the right-hand panel:
   Set the Terminal Server licensing mode
5. Double-click the aforementioned setting
6. Change the option (directly below the heading) to “Enabled”
7. Select “Per User” from the drop-down box (below the heading: “Specify the licensing mode for the terminal server”.)
8. Click ‘OK’
9. Close the “Group Policy Object Editor” window

Great. The licensing mode has been changed but the setting won’t take effect until the service is restarted. We could open ’services.msc’ and connect to ‘TERMSVR01′ by using the ‘Connect to another computer …’ option in the ‘Action’ menu. This will allow us to administer almost all running services on TERMSVR01 … almost all. You’ll notice immediately that you cannot start/stop the ‘Terminal Services’ service from this management console, so we need to find another way to do it.

The easiest way I know to accomplish this task is to use the WMIC command from the command prompt.

Step #2: Restart a remote service using WMIC

1. Open a command prompt
2. Type the following command (then hit enter) to stop the service:
   wmic /node:TERMSVR01 service where “caption=’Terminal Services’” call StopService
3. Then, type the following command to start the service:
   wmic /node:TERMSVR01 service where “caption=’Terminal Services’” call StartService
4. Close the command prompt

If everything was successful (and my assumption about the nature of the problem was correct), then I should be able to connect to the server using the Remote Desktop client. I fired up the client and voilà! It worked perfectly.

A while ago I needed to add a list of websites to the Internet Explorer’s “Trusted Sites” zone for multiple users, scattered across multiple terminal servers. IE’s “Enhanced Security Configuration” (ESC) is configured by default on windows terminal services and it’s normally a good idea to leave it intact.

However, this can have unintended consequences for users who require the use of websites that employ ActiveX, javascript, etc. because, by default, ESC does not allow those items to run. Sometimes, this means that the site in question will only be partially non-functioning. Other times, the entire site will be completely unusable. Furthermore, most users on terminal services have only a limited ability to actually modify the settings for an entire zone. Normally the best thing they can do is add the site to their trusted sites zone, if in fact the site is legitimate (i.e., “trusted”).

Originally, I explained to the users the steps involved in adding a site to their trusted sites, however many of the users used many of the same websites that other users were using. Also, new users needed to be trained on how to do this as well. Needless to say, it got very repetitive, very fast; so I came up with a “global” list of sites that can be trusted, and imported them to the registry on each terminal server. The list consisted of about 40+ sites, and I was able to generate the list mostly by exporting the following registry key:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains

…from a few user accounts who had already added most of the sites to their trusted sites zone. After grepping out the duplicates (among other things), I had my list.

Now, I’m going to cover two ways of making this list of domains “globally trusted”—both of them involve writing to the following registry key:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains

Pay attention! This is not the same key as previously mentioned. This key resides in the ‘HKEY_LOCAL_MACHINE’ hive, whereas the previous key resides in the ‘HKEY_CURRENT_USER’ hive.

The first way is via the following visual basic script:

Option Explicit

Dim DomainArray(5), strComputer, strHTTP, strHTTPS
Dim dwordZone, regPath, objReg, counter, subkeyPath
Dim subkeyValue
Const HKEY_LOCAL_MACHINE = &H80000002

DomainArray(0) = "testdomain0.com"
DomainArray(1) = "testdomain1.com"
DomainArray(2) = "testdomain2.com"
DomainArray(3) = "testdomain3.com"
DomainArray(4) = "testdomain4.com"

strComputer = "."
strHTTP = "http"
strHTTPS = "https"
dwordZone = "2"
regPath = "SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" &_
        "\ZoneMap\EscDomains\"
Set objReg = GetObject("winmgmts:{impersonationLevel = impersonate}!\\" & _
        strComputer & "\root\default:StdRegProv")

For counter = 0 to 4
        subkeyPath = regPath & DomainArray(counter)
        objReg.CreateKey HKEY_LOCAL_MACHINE,subkeyPath
        objReg.SetDWORDValue HKEY_LOCAL_MACHINE,subkeyPath,strHTTP,dwordZone
        objReg.SetDWORDValue HKEY_LOCAL_MACHINE,subkeyPath,strHTTPS,dwordZone
Next

This script will insert ‘testdomain0.com’, ‘testdomain1.com’, [...] into IE’s trusted sites zone when run on any machine. It must be run by an Administrator (or another user who has access to write to the HKEY_LOCAL_MACHINE registry hive), and the changes are global (to the machine).

The next way involves creating a “registry entries” (.reg) file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\testdomain0.com]
"http"=dword:00000002
"https"=dword:00000002

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\testdomain1.com]
"http"=dword:00000002
"https"=dword:00000002

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\testdomain2.com]
"http"=dword:00000002
"https"=dword:00000002

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\testdomain3.com]
"http"=dword:00000002
"https"=dword:00000002

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\testdomain4.com]
"http"=dword:00000002
"https"=dword:00000002

Just like the previous script, this must also be run by a user with Administrator privileges and any changes will be global to all users on the machine.

(Of course, you would want to customize these snippets of code to suit your needs.)

For more information, please visit the following sites:

Internet Explorer Enhanced Security Configuration changes the browsing experience
Enhanced Security Configuration for Internet Explorer
Internet Explorer security zones registry entries for advanced users

Quite an odd thing happened today… I encountered the same very specific error twice on two completely unrelated computers (two different clients). In _both_ cases, clamwin had unnecessarily quarantined the following file:

On both machines, this occurred during a scheduled scan. The symptoms of this problem are that windows will allow the user to login, but it immediately logs out after a second or two. Here’s how I fixed it in both cases:

1. Boot into the recovery console using a Windows XP install disk
2. Select the windows installation experiencing the problem and type the Administrator password when asked
3. Run the following command (assuming that your CD-ROM is D:\ and your hard drive is C:\):
   expand D:\I386\USERINIT.EX_ C:\WINDOWS\system32
4. Remove the CD from the drive then type ‘exit’ and hit ‘enter’ to reboot.

Once the computer boots properly (and allows you to stay logged in), use Malwarebytes, Spybot, HijackThis, etc. to scan your computer for viruses and/or spyware.

Update, 5 August 2009:

Just an additional note; you’ll want to be sure that the version of the file you copy from the installation disk is compatible with the service pack installed (it’s likely not). Symptoms of this incompatibility include things like explorer freezing when you try to shutdown or restart the computer. Uninstalling then Reinstalling the service pack should fix this issue. Alternatively, (and if ClamWin was the culprit) you could restore the old userinit.exe file from ClamWin’s quarantine directory… be sure to scan the file before doing this or else you could end up restoring an infected copy. So far, on every computer I’ve had to fix because of this (five and counting), ClamWin had falsely identified the userinit.exe file as a virus.

DISCLAIMER: This post assumes that both the source server and the destination server are windows servers. Once upon a time there was a UNIX version of MAS 90/200 but I’ve never had to administer that version so I cannot guarantee that any of this will work for it.

Here’s the scenario:

Your current server is dated and needs to be replaced; you need to move MAS 90/200 data to the new server, and you’d also like to keep your existing users/roles… basically you’d like to move the data with the least amount of trouble possible. To do this, the following conditions must first be met:

(1) Your new server has a clean installation of MAS 90/200.

(2) Both installations are the same version; they both have had the most recent service pack installed from Sage (which you can usually download from their support site however you’ll need an active account)

(3) The data on the old installation is at the appropriate level (i.e. it has been converted/updated to the format required by the latest update/service pack.)

(4) The MAS service has been stopped on both servers (this service can usually be found in the “Services” snap-in, within the Microsoft Management Console.)

If these conditions are met, then the only thing you should have to do is copy the following directories from the old MAS 90/200 directory (Usually something like: “C:\Program Files\Sage Software\MAS 200\Version4\MAS90″) to the MAS 90/200 directory on the new server:

(a) All “MAS_XXX” directories (where XXX is the 3 character company code)

(b) MAS_SYSTEM (yes, if asked to overwrite)

(c) MAS_USERS (yes, if asked to overwrite)

(d) Reports (yes, if asked to overwrite)

Depending on your environment, you may need to update the MAS client on each workstation. On my network, MAS runs in a terminal services environment so the only thing *I* need to do at this point is run Wksetup.exe from the MAS90Wksetup directory (one time only, on the new server).

Sometimes after running the workstation setup program, your users will get an error stating that you are out of licenses. To fix this, copy the following file:

To:

Be sure to select “yes” if asked to overwrite the existing file.

That’s all there is to moving the data, however there is one problem you are likely to encounter:

Data location for company xxx is invalid

Or, when you try to access a module for a client, you’ll get an error message about certain modules not being activated. Just close the error message and check the following:

(1) Select ‘Utilities’ -> ‘Data File Display and Maintenance’ from the menu at the top of the screen and click ‘OK’ on the warning message that appears.

(2) Click the ‘Browse’ icon:

(3) You’ll need to navigate to the ‘\MAS_SYSTEM\SY_Company.M4T’ file, and click ‘Open’

(4) Then, at the bottom of the window, you’ll need to select the ‘Key Scan’ button in order to select the company that you’re having problems with:

(5) In the window that appears, look through the list of companies until you see the company that you’re trying to fix. Double-click the company, or, single-click the company and then click the ‘Select’ button.

(6) Now you should be back at the “Data File Display and Maintenance” window; click the ‘Edit’ button and select key #13 (AlternateDirectory$) from the drop-down menu:

Clear the data in the ‘Change’ field and select ‘OK’. Do the exact same thing for key #14 (AlternatePayrollDirectory$). When finished, just close the ‘Data File Display and Maintenance’ window by clicking the ‘x’ in the upper right-hand corner.

Repeat these steps for every client/company that you’re experiencing issues with. There are other errors that can occur, specifically this one:

Instructions on how to address this, here.

The users of one of the companies that I manage (I.T.) send a lot of e-mails with MS Word/Excel attachments. A while ago, they decided to ignore my protests and upgrade to Office 2007; aside from the fact that Office 2007 sucks, this created a rather annoying *issue* for them whenever they sent a Word or Excel attachment via e-mail—about half of their recipients couldn’t open the attachments. This is a rather easy problem to deal with so I didn’t pay it much attention in the beginning… actually it’s not a problem at all, the software is doing exactly what it’s supposed to do: Force people (i.e., the recipients) to believe that they have no choice but to upgrade when in fact, they don’t. If this weren’t the case, then why wasn’t the Office 2007 Compatibility Pack included in the latest Office 2003 service pack (which was released September 18, 2007; eight months AFTER Office 2007 was released for retail on January 30, 2007)? But I digress… I could be here all day griping about Microsoft’s shady business practices. So anyway, in the beginning, I told the users to tell their recipients that they needed to install the aforementioned compatibility pack, I even gave them the direct link to the download. I also told them that as an alternative, they could save their documents in Word or Excel 2003 format. Both of these options proved to be too much for them (or their customers) to handle, and since I’m the I.T. guy I’m expected to “just make it work”. It’s ok, that’s what I get paid to do, so what did I do? Rather than travel to three different locations and make changes that would be reversed either at random, by the users, or by an update; I inserted the following lines in their login script(s):

Option Explicit
'Set word and excel 2007 default save formats
Dim objShell
Set objShell = CreateObject("WScript.Shell")
objShell.RegWrite _
"HKCU\Software\Microsoft\Office\12.0\Word\Options\DefaultFormat", "Doc", "REG_SZ"
objShell.RegWrite _
"HKCU\Software\Microsoft\Office\12.0\Excel\Options\DefaultFormat", "56", "REG_DWORD"

They only have about three different login scripts for the entire domain so this wasn’t too hard, I didn’t even have to leave the office

This changes a user’s default Word and Excel save formats to the Office 2003/XP format. If you put this in a login script, it will be run every time the user logs in (thus, changing the setting). This is exactly how Office 2007 changes this setting so there’s really no harm in setting it every time a user logs in. Also, running it automatically upon login prevents users from changing this setting permanently because it will be reset once they login (after shutting down for the evening or logging out for example).

Now I must admit, a part of me feels dirty for doing this. A part of me wanted to tell them that their only options (aside from telling their customers to upgrade) were the two that I already gave them (which, if it weren’t for my little addition to their login scripts, would be very true). I wanted to lecture them on why they shouldn’t be using proprietary software (and paying through the nose) for things that could be accomplished just as well, if not better, using free software. I wanted them to understand that this is what happens when your business depends on proprietary software–you become the manufacturer’s prisoner.

However, if I had attempted any of these, I would be less one client and they would have just found someone else to prolong their suffering–at least this way I get to keep my client.

I’m sharing this experience in the hope that if we spread this around, we can stifle the proliferation of OOXML formatted documents (I know it’s hopeless, but you can’t say I didn’t try).

If you’d like to know more about why it’s bad to send Word/Excel/Powerpoint/etc attachments, click here.