SPEWed on!

SPEWS the 'have a go' hero of spamming has got us! Being a Telewest customer it was only a matter of time I guess but the upshot is that we are not getting through to some of our contacts as they are using the SPEWS list to keep spam to a minimum.

Having ranted a little at Telewest for not sorting out their customer base and fixing the problem they did give me a smart host I could use for routing my mail, an IP that wasn't in the blacklist. Previsouly we had tried to route as much mail directly using DNS but this has forced our hand so now we have to set a smart host.

A quick change from 'Use DNS to route....' to 'Forward al mail through....' and setting the IP/DNS name in the field below and all mail was now going out through a new route and more importantly wasn't getting thrown into the big at the other end.

If only ISPs took a hard line on users closing open relays.

IE7 crashes Active Desktop

It appears now the WSUS is alive and kicking again we are playing catchup, some users have had this little beauty.

If IE7 doesnt manage to finish its install and cleanup process completely (usually because a user shuts down before completion) the .htt files used by active desktop are not upgraded to the new IE7 version. This results in the active desktop crash showing the recovery button. Clicking the button just throws up a script error.

To fix this you have to change a registry entry in the current user tree:

HKEY_CURRENT_USER = &H80000001
strComputer = "."
Set objReg = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")
strKeyPath = "Software\Microsoft\Internet Explorer\Desktop\SafeMode\Components"
strValue = "0"
ValueName = "DeskHtmlVersion"
objReg.SetDWORDValue HKEY_CURRENT_USER, strKeyPath, ValueName, strValue

Save the text as a .vbs file and get any users with this error to run it and fix active desktop.

Why are we even using active desktop? Well we use it to display the company logo in the centre of the screen and prevent everyone having everything from hot babes to football logos on their desktop!

McAfee Addins throw a wobbly

Here is a nice error thrown up by Mcafee today. Doing a staged upgrade of our old VirusScan software to the latest 8.5.0 enterprise version all appeared to be going well however on reboot several of our users were getting the following error:

Having logged on as myself I was not seeing this error. The extend.dat file is basically a copy of some registry settings that are put there to speed things up when opening Outlook. Upgrading over the network had done everything right in the registry but Outlook keeps going back to this file instead of copying the registry settings to a new one.

In the end an easy fix, delete the extend.dat in the path given in the error and Outlook recreates it the next time it is launched. Microsoft knowledgebase covers it here: http://support.microsoft.com/kb/204951

WSUS 3.0 - Client connectivity fixed!

Well the clients didn't do quite as I expected. Having rummaged through the IIS tree it seems that WSUS installs to BOTH websites.

It looks like if you already had WSUS/SUS of some description on your server and then upgrade WSUS will use another port for its site. The next port it will attempt to use is 8530. You can check the port in use by:

1. Open computer management


2. Expand IIS near the bottom


3. Expand the 'web sites' folder and highlight your WSUS site


4. Right-click - Properties will show the general tab


5. Look for the port field

Having spent some more time sifting through newsgroups and forum postings it seems there are a lot of people in the same boat. To fix this error simply point your Windows Update clients to the new URL:

Simply edit your existing group policy which holds your current WSUS info and change the URL in the two boxes shown in the picture to read: http://wsusserver:8530

Your clients will need to update their group policy settings: 'gpupdate /force' and then run a forced update on the Windows Update client 'wuauclt.exe /detectnow'

With luck your clients will update as normal and also report back to the WSUS server any changes, before you would have all the clients listed but the reporting times would not update.

WSUS 3.0 has arrived!

WSUS 3.0 is out and available for a free download. I must say this upgrade can only be classed as amusing. We originally used to use the old hfnetcheck command line tools to download our updates so when SUS came out we were quick to jump at the chance and with each new iteration it has been getting better and better.

The first thing you will notice is the new interface that uses MMC, why they didn't do this to start with I will never know. It works and with the download of the reporting pack it does some nice pretty stuff with pie charts.

So last week we thought we would upgrade and upgrade we did, all seemed to go OK and hey presto! we could connect with our new MMC tool (at the loss of the website). So there I am checking through the logs on the DC's after our new Win2k3 addition and what do I find but errors on not being able to contact the WSUS server.

To cut a long story short I am now an expert on WSUS error codes after several hours of Googling said codes. It appears that although the default website was stopped in IIS and not used the upgrade had put part of the new WSUS 3.0 by default into the default website (leaving the v2.0 piece in the WSUS site we created originally) so now it seems like our WSUS install is currently on 2 sites. Anyone care to explain why this happened?

The upshot is due to the default site being stopped all the clients couldn't connect to update the client part and throwing errors and basically failing miserably. Having started the site up I await the 3pm update to see if the clients are playing ball again.

Although we have a nice MMC tool now (you will have to go around isntalling it on any PC's you want to use for WSUS admin) they have removed the website which although a tad on the slow side was handy for checking things out from client PC's. Oh well the price of progress.

Its Alive and multiple accounts event id 11.

Well the network managed to stay up and nothing untoward is appearing in the event logs regarding out Win2k3 changes so I am happy enough.

However....I did find something that was annoying me.

Event ID: 11

There are multiple accounts with name
MSSQLSvc/SQLSVR.uk.mydomain.local:1433
of type 10.

This error was appearing at random on the subdomain DC system log. Looking through I think this was ignored as it wasn't actually affecting the system and there were bigger fish to fry.

So here is the magic fix:

1. Install the support tools pack from your Windows disk. This can be found in the Support\Tools folder.
2. Run LDP from the run dialog box.
3. Click CONNECTION - CONNECT - OK to connect to the LDAP.
4. Click CONNECTION - BIND - OK, leaving fields empty again.
5. Click BROWSE - SEARCH, in the Base DN box enter your domain in LDAP format: DC=uk,DC=mydomain,DC=local
6. In the filter box enter serviceprincipalname= in my example above I entered: serviceprincipalname=MSSQLSvc/SQLSVR.uk.mydomain.local:1433 ,set scope to SUBTREE then click RUN.
7. You will get a listing of where it exists, we need to lose one.

In our case we had the SQLSERVER service running as a local system account at one time so there was an entry under the computer name and an entry under the user account which was now running the service. So to remove the name from the computer account we brought up ADSIEDIT.MSC, browse through the domain tree and found our server in question in the listing (this will depend on where your server exists and your OU setup), right-clicking - properties gave us its detail and browsing down to SERVICEPRINCIPALNAME we found the entry for MSSQLSvc/SQLSVR.uk.mydomain.local:1433 still there. Deleting and rebooting and we no longer get the errors in the log.

Network Upgrade Time

It is no coincidence that my blog starts the week after we decide to upgrade the network. Its been an interesting week at work, we have a two tier domain with a master domain only holding 2 domain controllers with a subdomain which contains 2 DC's and everything else!

Last week we went and put in our first 2003 domain controller. All seemed to go well so I am awaiting the fallout on Tuesday when I return to work. With the boss away its going to be interesting on my own.

The DC went in on the subdomain and was dcpromo'd up with DHCP and integrated DNS on it. We then set all the static PC's to use the new DNS server with the other server holding the FSMO roles for the subdomain.

The other DC was then dcpromo'd down to leave the single DC with the FSMO roles running Win2K and the new Win2k3 server. We also made the Win2k3 server the global catalog for the subdomain. So far all seems to be OK.

Next step is to get a new Win2k3 DC in the top level domain so that they are all talking the some language so to speak. Ideally I would like to remove all the old Windows 2000 DC's by transferring the FSMO roles to the new servers and remove the old DC's as they have been upgraded and upgraded since NT 3.51 so they deserve retirement.

And So It Begins

Who am I? Well I am part of a 2-man IT team supporting a Windows 2000 network with over 130 Windows XP clients. The company I work for is a manaufacturing company so we have a wide range of users from 3D designers to packers and assembly line people.

Why this blog? This blog is mainly for me to follow how the network evolves and how we manage it as a team. I will put down here problems I face and links to how they were solved, the idea being that if other people have the same issues the fixes are easier to find, basically save some leg work for my fellow IT compatriots. Also I might tend to vent my spleen about the state of IT and where we are headed across all fields, its nice to give your opinion even if noone is reading.

....so now it begins....