WSUS under Server 2008

I configured a WSUS server under Server 2008 and created a GPO to instruct all the other Windows VMs in my test environment to point to it. Although the GPO was being pushed out, the WSUS console did not detect any computers.

After speaking to some colleagues about this (thanks Rob!), I tried manually running a Windows Update from one of the clients. This produced the following error: 80072EE6

Googling this suggested the problem was an "unknown protocol" and one post suggested checking that the GPO settings for the intranet server included the "http://" prefix before the hostname. I checked and found I didn't have that setting. Adding it in and then forcing a gpupdate worked and the clients have started to appear.

Joining an OpenSolaris CIFS server to an AD domain

These notes are rough, but might prove useful in the future (or to someone else who had the same problem). I wanted to join my newly created OpenSolaris 2008.11 installation to my experimental Windows Server 2008 Active Directory. I followed the tutorial in the Solaris CIFS Administration Guide, but when I attempted the actual join command, it failed with LOGIN_FAILURE.

Here's the answer:

Firstly, make sure you have the IP address setup correctly, name added in /etc/hosts, DNS setup correctly in /etc/resolv.conf and /etc/nsswitch.conf. You make sure you are on the same domain as the Active Directory ("windows.zone" in my case).

Secondly, make sure your system clock is synchronized with the domain controller:

# ntpdate dc01.windows.zone

Then setup Kerberos by editing /etc/krb5/krb5.conf. This is documented in the manual.

Install the SMB Server using the package manager and start it up using:

# svcadm enable -r smb/server

Then try to join the domain:

# smbadm join -u administrator windows.zone

For me, this is where it failed. The mailing lists suggest that the problem might be related to smb signing. On the DC, I opened up the Group Policy Management tool and changed the following:

Computer Configuration\Policies\Administrative Templates\System\Net
Logon\Allow Cryptography Algorithms Compatible with Windows NT 4.0 -> Enabled

I then ran a gpupdate /force.

Finally, I read that the sharectl command on the OpenSolaris server should be run to use NTLMv2 authentication:

# sharectl set -p lmauth_level=2 smb

I re-ran the join command, and it worked properly. OpenSolaris CIFS server now part of the Active Directory domain.

Installing OpenSolaris into VMware ESXi

I've just created a very small VM for installing OpenSolaris onto my ESXi box. The ISO CD booted in live mode to the desktop and I selected the option to install to disk.

The installer loaded, but at the point of "Finding Disks", the installer seemed to hang and no disk was found, even though format was displaying the disk okay.

Upon further investigation, I realised that the amount of RAM I had assigned to the VM (512MB) was causing a problem. By increasing this to 1GB, the disk was found and the installer worked as expected.

My guess is that this is due to Solaris deciding that with only 512MB of RAM, that some swap would be necessary, but it's not able to create it. Only a guess, but at least I now have a workaround.

Getting NFS4 permissions working correctly

Following the installation of the OpenSolaris server, I've had some problems with the NFS mounts. I've created an export for a fileserver (datapool/filestore) and although I have setup identical UID/GID maps between my clients and servers, when I mounted the filesystem on my Linux server, I found that files created were owned by nobody:nobody.

At first I thought this was due to some configuration problem in the OpenSolaris installation, but after trying it with the Mac as well, I realised that the mapping was fine. This then pointed to the OpenSUSE 11.1 installation.

The problem turned out to be the Domain setting in /etc/idmapd.conf. The value in this file was different from the OpenSolaris NFS domain. Changing that and restarting the idmapd process (which I did by rebooting the server as I had a kernel update to do), fixed the problem and I now map correctly.

The next step is getting a Samba and Windows client to authenticate me correctly with the OpenSolaris CIFS server. That might be more difficult, but I'll update here when it's done...

Building a test lab

Thanks to the Technet subscription that work has provided for me, I'm now in a position to build my own test Windows network. The purpose of this is to help me get a grip on Windows Server 2008, some Active Directory, Terminal Services etc., and potentially some other non-MS tech such as Citrix XenDesktop [Express].

I've been thinking through the planning of this test lab and recognise that I need to create a network. I can either create a new, completely virtual network and put my VMs on it, routing this to my physical network using a dual homed VM appliance, or I can create the test network in a different address range as my "live production" network and assign the IP addresses so that they don't overlap.

The latter seems the easiest way of doing it (although I may be proven wrong when it's built!).

So, assume my local network is 192.168.0.0/24 (it's not, but I'm not stupid enough to put my real subnet on the 'net!). I'm going to slice up the subnet as follows:

192.168.0.1 - 192.168.0.99 = static range for production network
192.168.0.100 - 192.168.0.150 = DHCP range for production network
192.168.0.151 - 192.168.0.200 = static range for test lab network
192.168.0.201 - 192.168.0.254 = DHCP range for test lab network

How do I determine whether a plugged in device gets a production or test DHCP address? Ultimately it will depend on which DHCP server responds, but the reality is that it shouldn't really matter. Both servers will allocate an address that is routable to the Internet and will resolve the DNS. For anything that will be permanent, I'll allocate a static IP anyway.

My production network has the DNS suffix of local.zone, and I contemplated creating the Active Directory as a sub-domain (windows.local.zone). I think that it will be easier though if I simply create a new domain (e.g., windows.zone) and manually create a DNS forwarder to local.zone when appropriate. This keeps the production network (primarily non-Windows based Solaris, Linux and Mac OS X with a non-domained Vista) from interfering, or depending on, the test lab.

If either of my readers(!) spots anything obviously wrong here, please let me know!

VMware Certified Professional

After a week of revision, plus a couple of years worth of hands on experience and the VMware Fast Track course, I took the VCP exam this morning. Pass mark is 70 and I managed to get 86 which was fine, especially as I remember the struggle that was the SCSA upgrade.

But the IT world does not stay still, and in these days of economic uncertainty, the market is only going to get more competitive, so with the VCP now under the belt, it's time to turn to the next cert... CCNA refresh? Something Citrix? Red Hat? Microsoft? Hmm.

An OpenSUSE quickie

The command line tool for patch and package management on OpenSUSE is "zypper". I've used zypper to list patch updates using:

# zypper lu

The patches can be added (updated) using:

# zypper up

Because I never got around to reading the man page, I didn't realise that both the above commands have an implicit "-t patch". I also didn't realise that "-t package" applied to the above commands can be used to display and update packages to a later version.

# zypper lu -t package
# zypper up -t package

Currently installing 83 package updates...