Domain authentication can be achieved relatively simply, by using either Winbind (part of the Samba project) or the new kid on the block, Likewise. Likewise-Open offers a simple procedure for joining domains, and the new version comes packaged with it's own version of Kerberos. It also hashes the Windows SID into a UNIX UID in a consistent manner - so the UIDs are always the same across your entire environment. Sounds perfect, right? Well, no. Not quite. The problem with Likewise-Open, is that it's difficult to integrate with Samba. Though it does ship with a "compatibility module" called lwi_compat, which allows Samba to hook into Likewise's authentication module, I found this quite difficult to get working, and I only achieved partial success through guesswork - as the documentation didn't actually help much, given they only officially support Samba 3.0.x (while Ubuntu now uses 3.3.x). When I did get it going, however, it only recognised the Windows users' primary group, not any of the other groups they were members of. This meant that my (possibly overly) complex system of ACLs and user directories just didn't work at all. So, on to Plan B...

When I read through the short (but sweet) Ubuntu Wiki article entitled ActiveDirectoryWinbindHowto, I felt like somewhat of a fool after reading a small, illusive section called Adding more than one Linux machine to a Windows network. Bingo! This section described a problem whereby the traditional Winbind domain authentication method would lead to inconsistent UIDs across the network, and thus cause headaches when trying to achieve anything like what I was aiming for. It suggested using a method of mapping SIDs to UIDs called RID. I assume this stands for Relative ID, which is another kind of ID Active Directory uses to track users within a domain. These can possibly clash from domain to domain, so it is advised not to use this method when your network contains a trust between multiple Windows domains, but for the simpler setup (like my own) it's a godsend.

This meant that I could use RID mapping within Winbind, which is part of Samba itself (so no troubles integrating those two), and achieve a consistent SID-UID mapping scheme across the network, allowing me to finally enable access to the file shares via. NFS. Amazingly, NFS "Just Worked" straight away, and I've written some nice wrapper programs around chown, getfacl and setfacl to set the correct owner and permissions on entire directory trees, which saves a lot of time when your UIDs are changing as often as mine were! I'm also using autofs to automatically map user's home directories on the Linux machines, which has proven itself to be very useful. I just used static fstab entries to map the other "general" file shares, like software and media - as I couldn't seem to get autofs direct maps working (apparently they are only partially working in Ubuntu anyway, but it seems as though they are completely broken to me).

On a side note, I've also just finished developing a Python-based rsync backup program, which allows me to write a _very_ small script to backup remote servers using rsync over SSH, and tar up the contents of all the servers into one archive. This is really useful, as I have a lot of disparate locations on different servers that all need to be pulled onto the backup drive every night. Now though, I should really concentrate on some revision for the exams I have after Christmas!

Happy holidays, everyone! (That's Merry Christmas and a happy new year, but just between you and me).

For example, when setting up Outlook Anywhere (the rebranded RPC/HTTP feature of Exchange, allowing Outlook users to connect from outside the organisation) I discovered a lot of "Sync Issues" appearing in my Inbox. The messages all had a common theme:

11:19:07 Synchronizer Version 12.0.6315
11:19:07 Synchronizing Mailbox 'User'
11:19:07 Synchronizing Hierarchy
11:19:07 Done
11:19:09 Microsoft Exchange offline address book
11:19:09              Not downloading Offline address book files.  A server (URL) could not be located.
11:19:09       0X8004010F

Clearly, something was wrong with the Offline Address Book. I was only getting these messages when using Outlook Anywhere, however, so this issue was obviously specific to RPC/HTTP.

Looking up the error code, I found that the problem I was experiencing was very common, but that nowhere seemed to have the ultimate repair. The information available was sparse, and I had to put together my own solution - which I will document below.

First, I registered an extra DNS (A) record for my email domain, called "autodiscover". I must be clear here, that this is for the mail domain, not for the domain used to access your OWA site. For example (and we'll go with the Microsoft classic here), if your users have addresses such as user1@contoso.com, user2@contoso.com and you access your OWA via https://mail.contoso.com/owa, then you need to register an A record for autodiscover.contoso.com.

Next, I prepared a new certificate request, that would hopefully end up with me obtaining a certificate that I could use to replace the current one, which would be valid for both mail.contoso.com and autodiscover.contoso.com (to continue with our example) - so that my Outlook clients could successfully access the autodiscover service, and download the OAB. To do this, I used the following EMS command:

New-ExchangeCertificate -domainname mail.contoso.com, exchange.contoso.local, autodiscover.contoso.com -Friendlyname "Contoso Exchange CAS SAN Certificate" -generaterequest:$true -keysize 1024 -path c:\certrequest.req -privatekeyexportable:$true –subjectname "c=GB o=contoso inc, CN=mail.contoso.com"

This command requires a little explanation. The -domainname switch is used to specify a list of addresses for which this server is valid. This is called a SAN (Subject Alternative Name). Not all CA's support SANs, but Windows Server 2008's CA Services does, which I will come back to later. Next, we give the certificate a "Friendly Name", which is just a reference for you, the administrator. Then we specify that we are looking to generate and save a request, and that we want to be able to export the private key. The Subject Name is important, but also slightly confusing. You must specify your country code (US, GB, ES), your organisation name, and Common Name (CN) - which is the most important one. This must be the URL used to access the SSL service using a web browser, so mine was mail.contoso.com.

Once this request is saved, I passed it on to my CA to get the certificate issued. If you're using a 3rd party CA (like VeriSign), then you'll have to check first whether they support SANs. I use self-signed certificates, and my CA is running Windows Server 2008, which does support SANs, so I issued the request internally. This is done by accessing the CertSrv website, at http://servername/certsrv, and clicking the "Request a Certificate" link. Then, I chose "Advanced Request", and pasted the reqest file's contents into the box, and picked the "Web Server" template.

This presented me with a downloadable certificate, which I saved locally in CER format on the exchange server. Then I used the following command to import the certificate:

Import-ExchangeCertificate –path <certificate>

Once the certificate was imported, I enabled it for use with exchange. A similar command is used for this:

Enable-ExchangeCertificate

This prompted for a list of services, where I entered IMAP, IIS, SMTP as these are the default installed services. Only IIS actually gets used here, so I shouldn't worry too much about this one. If you're not sure, then just enter the same as me. Lastly, it asked for a thumbprint, which I copied and pasted from the output of the import command. Finally, after accepting the confirmation, the certificate was enabled.

And that was it. Both OWA and Outlook Anywhere are now working perfectly, and hopefully this post will help at least one other lost soul with the same problem!

The basic idea is that Firefox has a file called profiles.ini, which takes care of all the configured profiles, and where they are stored. I used this file to change the default profile location to within the user's home directory on the file server. I had to use a home drive, mapped to the root of my users' folder redirection directory on the server, as I presumed UNC paths were unsupported in the .ini file. I did this with a GP Preference drive map using the %USERNAME% variable, and an amazing feature of GP Preferences - parsing and even altering ini files. You can specify which section of the ini file you are interested in, and which key you want changing. How useful! My policy looks like this:

You can probably work out what's going on here, but I'll give a quick overview. Basically, you specify the ini file to edit - in this case it's %APPDATA%\Mozilla\Firefox\profiles.ini. Using the %APPDATA% variable means that it will always resolve to the correct location in the user's local profile, whether they are on XP or Vista. Then we specify the section of the ini file - I'm interested in Profile0. This is the only profile present by default, but allows users to have multiple profiles if they wish without overwiting their settings when they log off. Finally, you specify the key to change, and what to change it to. I rename the default profile to Firefox, and change it's location to H:\Firefox. Also, this path is not relative, so I have to change IsRelative to 0.

OK, so now we have the Firefox profile location sorted, we need to make sure that folder exists - or Firefox will just overwrite our changes and make it's own folder in the default location. It's easy to use GP Preferences for this as well - as there's a Folders preference category. So I just made a new folders preference for \\zeus\UserData\%USERNAME%\Firefox, with the action of create (zeus is my main DC and File Server). I used the UNC path to be sure that the folder is created, even if the drive map hadn't come into effect when this preference was applied. Also, a little trick I had to pull here was ticking the checkbox titled Run in logged-on user's security context on the common tab. This is because only the user has permissions on their home directory, so this preference needed to run in the context of that user for it to work successfully (without access denied errors).

Once this was finished, the system started to work flawlessly. I copied the contents of existing Firefox profiles to the newly created directories, and they were picked up by Firefox with no problems. New users get blank profiles as expected, but they are stored on the file server instead of the local machine. One little issue I have encountered is that a user can't logon at more than one machine, and start Firefox - as the program can't lock particular files in the profile. This just results in a message saying this Firefox is already running though, which is pretty much correct (and I can't see why this would ever cause problems for the user).

The last trick I employed, to make things a little speedier and to reduce uneccesary file server traffic, was to disable disk caching on the roaming Firefox profiles. To do this, I used a file policy in GP Preferences to copy a tiny user.js (Firefox's preference file override) which contained only one line:

user_pref("browser.cache.disk.enable", false);

This turns off disk caching completely, which will not only save space on the file server, but should speed things up as well. I hosted this file elsewhere on the file server, and told the file policy to simply copy it into place, within the user's Firefox profile. Here's the preference:

So there you have it, my technique for enabling roaming Firefox profiles. If you've achieved the same through a different method, or have any ideas on this this could be improved, then I'd love to hear how - feel free to comment on this post.

Thanks to the MSDNAA program, I'm able to try out the latest version of Windows Server in the lab. I opted to migrate my domain accross to a new machine, instead of performing an in-place upgrade. Personally I feel this is a much safer bet, and tend to migrate domain controllers whenever I'm doing something pretty major to a DC.

So far everything looks good, I've upped the forest and domain functional level to Server 2008, so I can now take advantage of some of the new features - though I'm yet to find out what they all are! The best thing so far (by a mile I'd like to add) is the addition of Group Policy Preferences. Although it's annoying having to install the Client-Side Extensions on every machine in the domain (that is if WSUS isn't in use), the gains faw outweigh this bit of pain. I only wish an MSI could have been released, so that it could easily be pushed out using the existing Group Policy infrastructure. Never mind, eh?

Anyway, on with the good! The new GP Preferences allow an administrator to define, amongst others, drive maps for client machines, printer connections and power options. As you may be thinking, this just about does away with the need for logon scripts! Most, if not all of the common tasks that are performed with logon scripts can now be done from a group policy object.

There are also a lot of changes to the way Active Directory works. In Server 2008, Active Directory Domain Services can be installed on a machine, without actually making it a DC. What this means is that a standard server build can be 'sysprepped' with the files required for promoting the server to a DC, without actually doing the promotion. Also, Read-Only Domain Controllers (RODCs) have been introduced as a new feature. Essentially, an RODC just caches queries from a normal DC, usually located at another site - apparently allowing for faster logon times at remote sites with slow links. After discussion with a colleague, however, the benefits of such a system are maybe not quite as advertised. For example, only one RODC can be installed per site - so larger sites can't benefit from the redundancy and load balancing offered by multiple DCs, if RODCs are used. Also, the much-touted security advantages of using an RODC aren't as they seem either, as the database can be just as easily written to, just through another "normal" DC.

More on this later!

To create the VSS snapshot, I used a script sourced from an MSDN blog called CreateShadow, which I modified slightly to suit my purpose. I had it keep the temporary variables script, so I could use it later on (once the backup has finished) to delete the snapshot.

Once the snapshot is created and exposed, I used Robocopy with the mirror (/MIR) switch, to copy the contents to the backup drive. It just so happens that the backup drive is connected to a Samba server running on Ubuntu. This meant that I ran into a problem with timestamps whereby files were always classified as "newer", even if they hadn't changed at all since the last run. I fixed this by using the Fat File Times (/FFT) switch which gives a 2-second granularity on the timestamp of files, which solved the issue straight away.

The backup having completed, the script calls the temporary variables script generated by the CreateShadow script, to reinstate the snapshot ID, which is then used to remove the shadow copy cleanly.

In theory, this is an extremely efficient and robust backup system - not to mention being completely free of any licence fees. I may improve it in the future by adding functionality with multiple backup sets - at the moment I only have one day to recover from any accidental deletions - barring the previous versions.

One thing I am stuggling with at present, however, is the fact that when the backup runs under scheduled task at 3am, a number of files throw access denied errors - namely any files or directories with special characters. This is a particularly strange issue as the process works flawlessly when launched manually. I am still trying to solve the issue, but I'll be sure to post an update if and when I find the solution.

There has been a network or file permission error. The network connection may be lost.
(<filename>)

I've been trying to find out the cause of this for some time now, while working round it by simply saving the file to my desktop and copying it over to My Documents.

Anyway, I have just found the problem. I had a little plugin installed that allowed the indexing service on Windows Vista to index a network location, meaning I could search the My Documents folder quickly. This was the cause of the issue, and removing the index solved the problem. I wanted to write the solution up here in the hope that this helps someone in the same situation.

Note: There have been other solutions to this problem cited, including anti-virus programs, and network congestion.The KB article for this issue is located here.

I've recently upgraded the my new server, adding another 4GB of RAM to bring the total to 8GB - to give me some more room for playing around. Also, I've decided that with all that extra memory I can upgrade to VMware Server 2.0 safely, and all seems to have gone well. Also surprisingly, the load on the machine hasn't gone up, even with the addition of 2 new virtual machines.

The first new server is an anti-spam gateway for my Microsoft Exchange organisation, and is working flawlessly so far. Second is a Windows Server 2008 machine, which I plan to migrate the domain onto some time in the future. I plan to do some work with the brand new O/S, and see what's what. I'm sure there will be plenty of material to keep up-to-date with, so keep checking back!

I was preparing to send the thing back to Dell, when it happened one night and I checked out the event logs. It turns out that Windows Update was resuming the machine from hibernate - and then updating itself. After turning this off, I've had a good night's sleep! Also, Windows Defender was scheduled to scan the machine every morning at 2.00am, so that's been disabled too.

-

I hope this post can provide answers to anyone else experiencing a similar issue.

This post

made extremely interesting and informative reading – if one can understand the material in that post, then a lot of load issues can be easily resolved– especially IOWait issues (my particular concern). My issue turned out to be a mixture of the settings above, and Postfix misbehaving.

See the word document here.

Update: Advice followed, PDF available here.

Cacti is a complete network graphing solution designed to harness the power of RRDTool's data storage and graphing functionality.

Brilliant. Network graphing is good, I want to see pretty charts and graphs about how my network is doing. So I gave it a go. Here's some of my ups-and-downs, and the end result.

First, I needed a linux machine to try this on. Cacti itself obviously wasn't enough of a challenge for me, I wanted to get it to work on an operating system with which I had very little experience. I chose Ubuntu Server 7.10 - I've worked with Ubuntu before, and I like the Aptitude package manager which would make this project somewhat easier for me.

So first of all, I installed the O/S. I'm using a Virtual Machine on my main VM host, which had some RAM to spare. I only have the machine 128MB, as I'm not going to be asking too much of it (hopefully). I didn't specify a LAMP install, even though that is exactly what would be required. I wanted to do all the fiddly stuff later on.

Once the O/S was on, I needed to install the required packages, and then Cacti itself. Cacti requires a web server, with PHP and GD (the image library), and a MySQL server. I followed this guide to get them all installed on this new machine, and then extracted and set up Cacti.

Worth noting here, is that when importing the cacti.sql file into the MySQL database, I first created the database called "cacti", then modified the cacti.sql file, adding "use cacti" to the beginning of the file - otherwise an error stating "no database selected" would appear.

Once the database was setup, and Cacti was extracted - I pointed Firefox to http://cacti/cacti (I had a creative moment and called the Cacti server cacti). The setup process was web-based from here-on, and Cacti was installed in a matter of seconds.

So, now I added my hosts (after enabling the SNMP service on my Windows Servers, and configuring the community), and created some graphs. Just network traffic graphs at first. After a few polls, I was amazed to see the graphs populating perfectly. After following these instructions I made them look so much better (maybe not sexy, though!), and the result was something like this:

Wonderful. Pretty graphs showing me how much the internet connection is being used. 100k eh? Somehow I think paying for 20Mb isn't worth it!

OK, so now I have lots of nice graphs, I wanted to get a Network Weathermap working - which is like a virtual network diagram, showing the traffic between each node on the map - as it reads the data from the same source as Cacti.

This was much easier than I thought - after adding the nodes and links into the config file, the values took on the colours of my scale as they should - and I had a lovely diagram of my network with automatically updating traffic information! Here's the end result.

And there we have it! Not at all as bad as I was expecting. I do hope this will be of help to anyone wanting to do something similar.