Problems installing Windows Server 2003 SP2 using automatic updates

This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few days back, I noticed that I was unable to access websites as I had lost connectivity to my DNS server. When I checked the console, I found that my server had failed to install an update… Windows Server 2003 SP2 as it happens, which Windows Software Update Services (WSUS) had pushed out via the automatic updates mechanism. I restarted the machine and waited as it restored the prior configuration, running the software update removal wizard (at least it recovered cleanly), then waited as WSUS tried to push SP2 again. As the repeat update ran interactively, I found the problem – for some reason, towards the end of the installation, the following message was displayed:

Administrative Privileges Required

You must be an administrator of this computer to run this utility.

Log off, and then log on using an administrator account.

(even though I was logged on as the domain Administrator). After clicking OK, the installation continued before reporting:

Automatic Updates

You have successfully updated your computer.

You must restart your computer for the updates to take effect.

I’ve not seen any issues since the restart and the service pack seems to have applied successfully but checking the system event log reveals two entries describing the original problem:

Event Type: Error
Event Source: Windows Update Agent
Event Category: Installation
Event ID: 20
Date: 16/03/2007
Time: 06:00:19
User: N/A
Computer:
servername
Description:
Installation Failure: Windows failed to install the following update with error 0x80242007: Windows Server 2003 Service Pack 2 (32-bit x86).

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 57 69 6e 33 32 48 52 65 Win32HRe
0008: 73 75 6c 74 3d 30 78 38 sult=0x8
0010: 30 32 34 32 30 30 37 20 0242007
0018: 55 70 64 61 74 65 49 44 UpdateID
0020: 3d 7b 39 34 35 32 35 30 ={945250
0028: 33 43 2d 30 35 42 45 2d 3C-05BE-
0030: 34 41 36 34 2d 39 39 45 4A64-99E
0038: 44 2d 39 41 35 39 46 37 D-9A59F7
0040: 44 36 35 33 39 38 7d 20 D65398}
0048: 52 65 76 69 73 69 6f 6e Revision
0050: 4e 75 6d 62 65 72 3d 31 Number=1
0058: 30 34 20 00 04 .

Event Type: Error
Event Source: NtServicePack
Event Category: None
Event ID: 4374
Date: 17/03/2007
Time: 15:16:38
User: N/A
Computer:
servername
Description:
Windows Server 2003 installation failed, leaving Windows Server 2003 partially updated.
The installation of the Service Pack did not complete, and a rollback to the pre-installation state has been initiated. A rollback is a two-step process. Step one is complete; to complete step two, click OK. To be reminded at next login to complete step two, click Cancel. After you complete the rollback, your system will reboot and you may retry the installation of the Service Pack.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

My other Windows servers seem to have updated without any problems; however this illustrates the risk of having WSUS automatically approve updates.

Showing hidden files in Mac OS X

This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I use hidden files (such as .htaccess) extensively on my website, so I needed to be sure that they were included with my local backup copy. Mac OS X doesn’t show hidden files by default (it all gets a bit messy otherwise – although they are visible in a Terminal shell); however I found a tip which details the commands to run in order to show hidden files in the Finder (this can be run using a standard user account):

defaults write com.apple.finder AppleShowAllFiles TRUE
killall Finder

To return to the default display, run:

defaults write com.apple.finder AppleShowAllFiles FALSE
killall Finder

I did find an application to display hidden files too but why bother if a couple of commands will do the trick? Even better, there is a workflow to show hidden files using Automator.

Woohoo! 8Mbps ADSL

This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Screenshot from router configuration showing 7552Kbps ADSL connectionPlusNet upgraded our ADSL connection to their “up to 8Mbps” service today. I’m told that it may take a few days to settle down (they advised us to reboot the router once a day for 10 days or so) but the initial connection was a whopping 7552Kbps (7.375Mbps). After the first reboot, this seems to have dropped slightly to a more typical 5.1Mbps but that’s still a great improvement over yesterday – and I live in the sticks where a few years ago we had to campaign to get our telephone exchange upgraded for a 512Kbps ADSL connection! It seems that Moore’s law applies to telecoms too (sort of… our costs haven’t dropped but we have seen a 10-fold increase in connection speeds over a 4 year period).

Call centres, offshoring, poor customer service and how to save some money

This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I can understand why outsourcing and, in today’s global economy, off-shoring is so attractive to companies. I just wish that companies would think things through a bit further than the initial impressions of reduced costs.

Because I work for a company whose core business is IT managed service (but never referred to as outsourcing!), I’ll steer clear of my feelings on that subject – suffice to say that clearly there is a conflict of interest there. This post is purely about my experiences as a consumer of outsourced and off-shored services.

Firstly, although I have no direct experience of this, I’m led to believe that the cost savings from moving services overseas are generally not as great as they may initially appear. The workers may be paid less, and the cost of office space in India (for example) may be lower than in Western Europe but in call centre situations there are telecommunications costs to consider, as well as the inevitable integration of the offshore systems and processes with the rest of the business. I frequently have cause to speak to an IT service desk in South Africa and am rarely happy with the outcome. Sure, the staff are friendly and English is well spoken but the telephone line quality is inevitably poor. I don’t know if it’s routed via IP or over low grade international lines but either way it is not good for conversation. Even for software development, there is an implicit need for integration with other products and teams based elsewhere in the world. Technologies such as VoIP and web conferencing services may help bridge the gaps but in my experience, occasional face-to-face meetings are required in order to cement a quality relationship (and good relations really help to get things done).

Whilst I can see that there are some benefits to be had from off-shoring, near-shoring is sometimes seen as a more practical alternative (certainly, one of my previous employers had a relationship with a company in Eastern Europe for offshore software development rather than further afield). From a business perspective, it’s often a lot easier to spend a day or two in another European city than to fly several timezones away with all the complications that entails (jet lag is really not conducive to efficiency – as I found on a business trip to New Jersey a few years back).

Getting back to call centres, I’m not always pleased with my bank (First Direct); however one of the main reasons I stick with them is that all of their call centres are UK-based. The staff may have a variety of regional dialects (who doesn’t?) but English is their first language – complete with an understanding of all the nuances and colloquialisms that are in daily use. Even so, a few months back, I wanted to know the telephone number for a branch office where the paying in machine had crashed half way through my transaction (my money had been taken but would it be credited to my account?). This branch actually belongs to First Direct’s parent company, HSBC, who only publish a central number for branch contact. And where do you think the call goes to speak to someone in the next major town? Yep. India. Who couldn’t put me through to anyone local that could give me an answer – all I could do was wait and see if the money appeared in my account (fortunately it did).

I’ve just come off the phone from my credit card company (Marks and Spencer Money) and the only thing that keeps my custom there is the shopping vouchers that appear in the post every few weeks. All I wanted was a replacement card. After negotiating the inevitable IVR system I finally spoke to someone who was unable to help me because his systems were updating (and could I please call back later). After I said that they should call me (and he said he worked in a paperless office so he couldn’t make a note of my details to call back), I threatened to close my account (I meant it) and he transferred me to a colleague whose system could issue me a replacement card. Result. Except that it shouldn’t be this difficult and I shouldn’t need to be so stroppy.

To be fair, this could have happened in a UK call centre too. John Lewis Financial Services is based in Birmingham and I gave up getting a satisfactory response from them after problems with their Partnership card. Ditto for Halifax Bank of Scotland, who I hope never to do business with again (although that’s becoming increasingly difficult as they are so large in the marketplace). Even Volkswagen Assistance were unable to renew the breakdown cover on my wife’s car this morning because of a system being unavailable and asked me to call back later, although they were prepared to take a note of my number and call me (if only everything in life was as reliable as a Volkswagen). My point is, that if the call quality is good and the person on the other end of the phone wants to go the extra mile to deliver great customer service then I’ll be happy to continue my relationship and if they don’t, then I won’t.

In another example, my wife received a letter from her bank to say that as her credit card was coming up for expiry and, as she hadn’t used it for a while, they would close the account if they didn’t hear from her. That’s fair enough – customers who don’t use their accounts are bad business – but when she called to speak to them about keeping the account open (an opportunity to regain some lost business) she found herself on hold for so long that she decided that she didn’t want the account anyway! Similarly, I found myself on hold in Tesco‘s call centre phone system for so long a few weeks back that the cost of my phone call was greater than the cost of the product that I needed a refund for in my online shopping!

To make matters worse, many call centres only publish national rate (0870) numbers (and other non-geographic numbers that are excluded from bundled/low-cost call deals) – in effect, they can actually make money from you whilst keeping you on the line so, if you want to reduce your phone bill when calling non-geographic numbers for call centres, check out say no to 0870 for a database of alternative numbers).

In my view, it’s the cost of lost business that companies need to consider when selecting their partners rather than basing decisions on cost reduction alone.

Right, enough of being Mr. Angry – it’s a beautiful sunny day – I’m going to leave my computers and phone behind and get out into the countryside!

Duplicate computer name prevents Active Directory domain logon

This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I came across an interesting problem a few nights back… I locked myself out of a Windows XP computer. Here’s how it happened, along with how I got back in.

First, I built a new Windows Server and inadvertently used the same name as an existing Windows XP computer. Then I joined the server to an Active Directory domain (from this point on, the machine that was originally using the computer name is unable to authenticate with the domain as its password will have been overwritten when the duplicate machine joined the domain).

I then turned on the Windows XP computer. Because this machine is a notebook PC and wasn’t connected to the network at the time, I logged in using cached credentials; however after installing a wireless network card and restarting the computer, I was presented with a message that indicated I could not log on to the domain. Unfortunately I didn’t make a note of the exact message at the time, but looking back, I can see the NetLogon event 3210 in the system event log, the description for which which tells me exactly the problem:

This computer could not authenticate with \\domaincontroller.domainname.tld, a Windows domain controller for domain domainname, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.

Realising my mistake, I logged on using a local account and tried to rejoin the domain. Except that I couldn’t, because, as per Microsoft’s advice, I had disabled the local administrator account when I joined the domain and all I had available to me were standard user accounts.

Luckily Daniel Petri has published an article with a workaround for when a Windows computer cannot log on to a Windows Server 2003 domain due to errors connecting to the domain. By removing the network cable and restarting, I could log on as a domain administrator using cached credentials. Then, I enabled the local administrator account and changed the computer name before moving the computer out of the domain and into a workgroup. I then rebooted (with the network cable connected), logged in using the re-enabled administrator account and rejoined the domain (with the new computer name), before disabling the administrator account again.

Phew!

SSH addendum

This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Since my recent posts about using SSH to securely remote administer Mac OS X, Linux and Windows computers, a couple of extra points have come up that are probably worth noting:

  • To use the console interactively, it may be better to use PuTTY (putty) than PuTTY Link (plink). In seems that PuTTY Link is fine for setting up a tunnel and then connecting using VNC, RDP or another remote control method but I found that control codes were echoed to the console window when I connected to a Linux of Windows computer and the command line experience was generally better using PuTTY interactively. This is because (quoting from the PuTTY documentation) “The output sent by the server will be written straight to your command prompt window, which will most likely not interpret terminal control codes in the way the server expects it to […] Interactive connections like this are not the main point of Plink”.
  • For another method of generating SSH keys, an online SSH key generator is available (I haven’t tried it myself).

Secure, remote administration of a Windows computer

This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I was going to call this post “secure, remote administration of a Windows computer from within Windows” but that sounds a bit odd, unless you realise that the last two posts have been “secure, remote administration of a Linux computer from within Windows” and “secure, remote administration of a Mac OS X computer from within Windows“. Basically, after getting SSH tunneling to work for administering Mac OS X and Linux machines, I thought that it would make sense to apply the same principles to Windows.

John Fitzgibbon’s comparison of free SSH and SCP programs for Windows 9x, NT, ME, 2000 and XP explains the various SSH server options for Windows but one option he doesn’t mention is Tevfik Karagülle’s CopSSH, which I found on a list of free SSH implementations recommended by OpenSSH.

CopSSH bundles parts of OpenSSL, OpenSSH and Cygwin into a Windows installer. It’s straightforward to install, and includes a GUI interface to activate a user for SSH, including the generation of a public/private key pair (saved to %programfiles%\copSSH\username\username.key and %programfiles%\copSSH\username\username.key.pub). The private key needs to be imported into PuTTYgen after which it can be saved in PuTTY’s .PPK format and used as previously described for Mac OS X and Linux. The only other point to note is that the sshd_config file is stored in %programfiles%\copSSH\etc and requires the same AllowTcpForwarding yes and PasswordAuthentication no settings as seen previously.

To access the desktop via VNC, I installed UltraVNC Server on the target machine noting there are two settings that need to be configured for a successful connection through the SSH tunnel:

  • A password must be defined for VNC connections.
  • Loopback connections must be allowed.

That’s fine for using an SSH tunnel to secure a VNC session, but why not tunnel remote desktop (RDP) connections to Windows servers instead of using VNC? In theory, all that should involve is changing the forwarded source port from 5900 (VNC) to 3389 (RDP) and setting the corresponding SSH port forwarding destination to localhost:3389 but Windows doesn’t like that, producing an error message as follows:

Remote Desktop Disconnected

The client could not connect. You are already connected to the console of this computer. A new console session cannot be established.

One suggested fix is to change the destination to use another address from the loopback range (e.g. 127.0.0.2) but I found this just directed me to my own machine (as might be expected with a loopback). For a while, it looked as though the resolution would be related to a change made in Windows XP service pack 2, which prevents connections to loopback addresses other than 127.0.0.1, and Microsoft knowledge base article 884020 includes a hotfix that alters this behaviour but I don’t think it helped me much (I later removed the hotfix and didn’t notice any differences). Eventually I got things working by creating a new forwarded source port of 3390 and destination of localhost:3389 for SSH port forwarding, after which I could connect using mstsc /v:loopback:3390.

It’s been an interesting few days getting acquainted with using SSH tunnels to securely connect to remote systems running a variety of operating systems – hopefully posting my experiences here will be useful to others.

Secure, remote administration of a Linux computer from within Windows

This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Yesterday I wrote about using SSH to securely connect to a Mac from a Windows PC. At the time, I suggested that the advice should be equally applicable to a Linux system, or even to a Windows Server with an SSH server installed and I’ve since tested it with a Linux machine (running Fedora Core 5).

The Linux process is almost identical to my original post for Mac OS X, except that:

  • The sshd_config file is found in /etc/ssh.
  • SSH is enabled in the firewall using the system-config-securitylevel command.
  • The SSH deamon is restarted using the service sshd restart command.
  • GNOME includes a VNC server called vino, which needs to be enabled (users of other graphical environments will need to choose an alternative VNC server).

(Also… RTFM… I spent a lot of time trying to work out why I couldn’t connect, only to find that I’d neglected to place the public key in ~/.ssh/authorized_keys).

Falko Timme has written an excellent tutorial on key-based SSH logins with PuTTY which outlines all the key steps (in fact, if I knew that existed then I wouldn’t have spent so much time writing up the process here!) but Jeremy Mates’ OpenSSH public key authentication article includes a useful troubleshooting guide for public key authentication problems.

VNC is all very well for forwarding the entire desktop, but X11 forwarding can be used to run individual X applications on the Windows machine. Because Microsoft Windows doesn’t include an X Window server, it is necessary to download an X11 port for Windows – I used XMing. Once XMing (and the XMing fonts) were installed and running, I edited my PuTTY connection to enable X11 forwarding and ensured that the sshd_config file on the Linux box included X11Forwarding yes (that was the default on my Fedora Core 5 installation) and could launch an xapplication from within the PuTTY terminal window with xapplicationname & (e.g. xeyes &) (I found this information at the Linux Documentation Project). XEyes is nothing special, so how about running a Linux application on the Windows desktop… try mozilla & or gimp & – it feels “wrong” but it’s also pretty impressive and oh so “right” at the same time!

Using XMing to run X11 applications on a Windows XP machine

Secure, remote administration of a Mac OS X computer from within Windows

This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

In a recent post about multimedia file format conversions, ripping DVDs, playback and more, I linked to a number of Mark Pilgrim’s “How To” articles; however there was one which wasn’t relevant to that particular post – how to use your Mac from anywhere (although it is intended for remote control of a Mac the advice should be equally applicable to a Linux system, or even to a Windows Server with an SSH server installed).

A few months back, I blogged about using creating an SSL VPN to access my network but Mark’s video explains how to open a single firewall port and use SSH to provide a secure tunnel through which other protocols (in this case VNC) can be run for remote administration of a single computer. I tried it earlier and it’s very straightforward. Best of all, the software involved is all freely available under open source licensing agreements!

I recommend downloading Mark Pilgrim’s video for a full explanation but the notes below explain what is involved (some of the Unix concepts may be unfamiliar to those more used to a graphical environment and my quick introduction to Linux for Windows administrators might be useful):

  1. Download and install the PuTTY, PuTTYgen, Pageant and Plink SSH utilities on a Windows PC.
  2. Using puttygen, generate a public/private key pair and protect it with a passphrase. Save the private key to a file on the Windows PC and copy the public key to the remote computer (e.g. within a text file transmitted via e-mail or FTP).
  3. On the Mac, open a terminal session (either using the OS X Terminal application or an alternative such as iTerm) and enter the following commands from the home (~) directory:
    • mkdir .ssh (this was already present on my machine as I already had the SSH server running).
    • chmod 700 .ssh (again, I didn’t need to do this).
    • chmod 600 publickeyfilename (the default permission set is 640).
    • mv publickeyfilename .ssh/authorized_keys
    • sudo nano /etc/sshd_config (non-admin users may need to su - to an admin account first as explained in my earlier post about running sudo as a standard user) and make the following edits:
      • Allow SSHtunnelling (also known as TCP forwarding or port forwarding) by changing #AllowTcpForwarding yes to AllowTcpForwarding yes
      • (Optionally) Prevent the use of usernames and passwords for login (the public/private key pair and passphrase will provide the security for the connection) by changing #PasswordAuthentication yes to PasswordAuthentication no
      • (OS X 10.4 only) Disable pluggable authentication modules by changing #UsePAM no to UsePAM no
    • Exit nano and save the changes to /etc/sshd_config (exit to the original shell if su was previously used to escalate privileges).
    • Generate an SSH key fingerprint (to prevent man-in-the-middle attacks) using ssh-keygen -l -f /etc/ssh_host_rsa_key.pub and make a note of the fingerprint.
  4. Open TCP port 22 on any firewalls/routers between the Windows and Macintosh computers and enable port forwarding to the appropriate internal IP address (it may be necessary to apply a static IP address to the Mac but I prefer to use a DHCP reservation).
  5. If the external IP address for the network is not static (mine is) then use a dynamic DNS service to assign a DNS name so that it may be located on the Internet.
  6. Within the OS X System Preferences, Open Sharing and enable Remote Login (restart the service if it is already running in order to pick up the changes made earlier to /etc/sshd_config). Because password authentication has been disabled, remote login (SSH) will only be possible from a machine with the appropriate private key.
  7. Although OS X includes Apple Remote Desktop, which is a VNC server, alternatives such as Vine Server (OSXvnc) offer additional functionality. In particular, VNC is insecure by default; however by selecting to only allow local connections (require SSH) and start the system server (i.e. run as a service, rather than in the context of a particular user), it is possible to run a secure VNC server each time the system is restarted.
  8. At this stage, it should be possible to create an SSH tunnel to the Mac. On the Windows PC, run pageant which is a PuTTY helper application (SSH agent) to cache the passphrase for the private key, which adds a level of security if the PC is compromised but which would also become a nuisance if it needed to be repetitively entered. Add a key using the private key file generated in step 2 and enter the passphrase that was used when created the key.
  9. Next, run putty and enter:
    • The hostname/ipaddress in the basic session options.
    • The auto-login username for the Macintosh for the connection data.
    • The privatekeyfilename for SSH authentication.
    • A new forwarded source port of 5900 and destination of localhost:5900 for SSH port forwarding.
  10. Save the session with an appropriate sessionname and open the connection. On the first connection, the host key will be unknown; however the reported key can be compared with the one generated earlier to ensure that the host is the intended target computer. Assuming that all is well and the connection is allowed to continue, then a Welcome to Darwin! greeting should be displayed, along with a shell prompt.
    • If the connection fails and there is a prompt for the private key then Pageant is not correctly configured.
    • If there is a prompt for a password then /etc/sshd_config was not correctly edited.
  11. Unless command line interaction with the Mac is required, the PuTTY window can be minimised. In order to create the SSH tunnel automatically at login, a startup shortcut can be created with the target of "%programfiles%\PuTTY\pageant.exe" privatekeyfilename -c "%programfiles%\PuTTY\plink.exe" sessionname
  12. Finally, a graphical connection may be initiated with a VNC viewer such as UltraVNC. The connection should be made to localhost; however because localhost:5900 has been defined as the forwarded port in the SSH tunnel, the request is securely transferred to the VNC server on the Mac.

It’s worth noting that when I originally tried to test this configuration from a remote network I was unable to get past my employer’s firewall; however there are plenty of unsecured wireless networks around which I could use to test the connection!

Note that the original information that provided inspiration for writing this post is licensed under a creative commons attribution sharealike 2.5 license and consequently so is the information contained in this post.

Running sudo as a standard user in Mac OS X

This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Apple Mac OS X has its roots in a development of BSD Unix and as such the command line should be pretty familiar to most Unix sysadmins. It does have one significant security flaw though – the default privilege level for a user is admin (although, to be fair, that is not the same as root, which needs to be enabled manually if required). Such routine use of administrative privileges is a dangerous practice – one which many Mac users will be happy to criticise Windows for; however, unlike versions of Windows prior to Vista, it is perfectly easy to operate a Mac using the principle of least user privilege – indeed, I perform all of my Mac OS X activities as a standard user although I’m asked to authenticate using an admin account for certain activities (in a similar manner to Windows Vista user access control).

Rather than enabling root access, OS X uses the sudo command to temporarily escalate privileges when required in a terminal shell (Linux Box Admin has an interesting article comparing sudo with root); however, by default, sudo will not work for a standard user – when I tried to run sudo command earlier today I got the following response:

WARNING: Improper use of the sudo command could lead to data loss
or the deletion of important system files. Please double-check your
typing when using sudo. Type “man sudo” for more information.

To proceed, enter your password, or type Ctrl-C to abort.

Password:
username is not in the sudoers file. This incident will be reported.

I could edit /etc/sudoers (the guide at MDLog:/sysadmin gives a good introduction to sudo) but I don’t know what security holes I might open in the process. One workaround is to enable the root account and use ssh root@localhost but enabling root access is really an unnecessary step. Instead, I prefer to use su - adminaccountname, after which I can sudo the appropriate command(s) and exit to return to a standard shell.