Rob Golding

If you work with Microsoft’s Terminal Services on a regular basis, you’ve probably come accross a printing issue at some point. The point of this post is to provide a potential solution to the problem whereby locally attached network printers cannot be used from a remote terminal services session. By locally attached, I mean directly connected via. IP address, and not by way of a print server. This is often the case with consumer grade network printers, or wireless equivalents.

The concept is simple - attach the network printer as normal, then share it. Then, connect to the share on the local machine - thus using the printer as it is connect via a print server - with the server being the local machine. Here are the steps required to achieve this:

• First attach the printer as normal. For the type of connection I am describing this is via. a TCP/IP port. So choose New Printer in Printers and Faxes, and then Local printer attached to this computer.
• When asked the type of port, choose TCP/IP, and enter the IP address of the network printer.
• Once the printer is connected, share it. This can be done from the wizard, or by using the Sharing and Security panel afterwards.
• Then, choose New Printer again, this time selecting a network printer. Then enter \\<machine_name>\<share_name> as the path to the printer. Obviously machine name is the name of your computer, and share name is the name with which you shared the printer in the previous step.
• Note: This step will not introduce a new printer item to your list of printers, so don’t be alarmed when nothing new appears. Just connect to the terminal server as in the last step.
• Once this is done, connect to your terminal services session and wait for a minute or two for the printer to appear. Note that version 6 of the Microsoft Terminal Services Client may be required for this to work.

Although it seems hacky, and untidy, this solution seems to work well, so I hope this will help at least one person out there. Happy printing.

While improving the network at my house (an indeed, the network which supports this very web server), I started to explore the world of network monitoring and reporting. I had heard quite a bit about Cacti before, but never considered installing it. That was mostly due to the stories I had heard about how unholy difficult the damn thing is to get working properly. “Don’t even go there” was my mindset. Until now, that is.

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.

Okay, so if you’re anything like me - and like things to be done properly first time (and also to look neat), then you’ll know what I mean when I talk about the separate _msdcs zone in DNS on a Windows AD DNS Server. Of course, you have to be a nerd, like me, to know what I’m talking about here also - but that’s assumed seeing as you’re reading this blog. I digress…

If you have ever reconfigured said DNS server, and recreated the DNS zones from scratch, you’ll know that the neat zone that keeps all the SRV records separate from the oh-so-important A records, disappears - and gets put in a folder under the usual domain root.

Well, I have a solution to the ever so pressing issue. Obviously the only way anyone is going to risk breaking their whole Active Directory network will be if, like me, they are so _totally_ OCD about this kind of thing.

So, if you’re interested, I’ve written a short article on how to restore this behaviour, and published it as always on maxms.net. If you think it might help you out, then here’s the link:

http://maxms.net/article/Restoring-the-Separate-_msdcs-Zone-in-DNS

But remember, follow that article at your own risk!

As an update to the previous post regarding the installation of a new IPCop as my network firewall, I have finally completed the configuration of its VPN service for use as a Roadwarrior. I can now connect to the IPCop machine from my laptop, using the OpenVPN client from anywhere in the world.

I was surprised with the ease of configuration once an addon called “Zerina” was installed. This made the process extremely simple to complete, even offering to package up an OpenVPN configuration file and certificate combination - so all that is needed to connect is one click!

With regards to the IPCop machine itself, it is one of the most stable servers I have ever put into operation. I literally installed the O/S (about 50mb) a couple of weeks ago - and since then there has been not one issue. Not even a restart - it’s just been chugging away on that old 400MHz Pentium II. I am in awe of the little thing - which is actually proving to be a damn sight faster than the overpowered and clunky ISA Server that I used to use.

Also, with the terrible OpenVPN logo, and the lack of suitable IPCop art, I hope the visio diagram to the left bears a resemblance to this post that could be appreciated by the reader. I definitely think it makes the post something special, would you not agree?

My latest project, to replace the bulky overpowered ISA firewall on my home network with a lean mean IPCop machine, was declared a great success a few days ago.

I am familiar with IPCop, as I used to use it a long time ago. Since then it has matured somewhat, but the feature set is pretty much the same as I remember. The new machine is a 400MHz PII, with 192mb RAM. It is sitting in the place of a Sempron 3000+ with 1GB RAM. Amazing, it’s doing the same job with a fraction of the power. And also, it uses a third of the electricity - 30W in total. Good news given the rise in energy prices!

The main challenge so far, which I still haven’t overcome, is how to get RoadWarrior VPN working, using the windows built-in VPN client, with L2TP/IPSec. This used to be trivial with ISA Server, but this isn’t quite the case with a linux firewall. I have been looking at other distributions such as monowall and pfSense, niether of which seem to spell out their ability to achieve this clearly. I am playing with a few of these on Virtual Machines, so hopefully I will come accross a way to do this before long - I’m starting to miss my RoadWarrior VPN server. How sad, eh?

As a matter of curiosity more than anything, I often wonder whether other people’s methods and practices for setting up AD are similar to my own. I will explain as best I can my own procedure, in an attempt to see how it compares to the rest of the IT community.

Firstly, I install DNS on the Domain Controller to-be. I don’t do any configuration on the service, just install it. Then, running DCPromo, I allow the wizard to configure the DNS Service for me. This makes sure that the two separate zones will be present - _msdcs.domain.name, and domain.name. This seems much neater to me, and I like to see this result - so I allow the wizard to take care of it.

When the domain is installed, the first thing I usually do is open up the default domain policy and remove all the password complexity options. These are usually just an annoyance - and unless the network has any particular security needs, I disable them all. Maybe leaving the length value at 6 if it’s inappropriate to turn it off completely. I like managing GPO’s from the Group Policy Management Console (GPMC), so that usually gets installed straight away.

In regard to the structure of the domain, I make an OU with the domain’s Netbios name in the root, and under that I create some OU’s as follows:

• Computers
• Distribution Groups (If Exchange will be installed)
• Security Groups
• Servers
  • Exchange Servers (for a special shutdown script)
• System Users
• Users

As for an explanation for that Exchange Servers OU, I make a shutdown script to stop all the exchange servers when it shuts down, to make the process a hundred times faster. I am so impressed by this technique, it works flawlessly every time. This OU allows me to assign the shutdown script via GPO to all Exchange Servers in the domain. Note that the DC stays in its own Domain Controllers OU that is created by the system automatically.

I guess at this point I’m feeling like I should do a backup of the DC. DHCP servers need authorizing, and Remote Desktop needs configuring. When that’s done, we’re basically there. Get the clients joined to the domain and we’re off!

I have no idea whether my procedure is similar to anyone elses, or in any way superior (or indeed inferior) to others. Give me some opinions anyway, it will be interesting to hear from the rest of the community.

For the first time in 7 months, I’ve finished writing a new article for my resource site - maxms.net. The article is entitled Folder Redirection with Group Policy in Server 2003 - it’s purpose should be explained fully in the title!

If this helps just one person out there, I will be happy. I’d be even happier if they contacted me to let me know it helped :). I hope this will signal a revival for the site, and I shall continue writing more articles as time allows. Any suggestions for future articles are welcome, just shoot me an email with the contact button up top.

For a direct link to the article, and some shameless self-promotion: Folder Redirection with Group Policy in Server 2003

Seeing as I’m getting into virtualization more and more recently, I decided to give the new beta of VMware Server 2.0 a go. I have a virtual machine for testing purposes on my desktop machine (a Dell Dimension 9200, E6600, 2GB RAM) – so this should prove a perfect test bed for the software.

I have a particular personal interest in VMware. The server that so many of my posts have been about as of late runs VMware - it and a couple of virtual machines provide me with my email, directory, file servers and websites. Because of this, I’m quite excited about the next release of VMware – and hopefully the transition won’t be too difficult.

Starting with the interface, which is the first noticeable difference one the installation is completed – there is nothing that has been kept from version 1 – a complete overhaul. It’s now based totally in the browser – on port 8222 (8333 for https) – using its own installation of Tomcat to be precise. This brought back bad memories of managing Microsoft Virtual Server 2005 on a client’s system – but once I started using the new interface, I began to like it more and more. It’s definitely an improvement over Microsoft’s attempt, and with the browser plug-in for Virtual Machine Remote Control (VMRC), it provides all the functionality of the previous console and more; even in firefox!

I can definitely say that the performance of VMware itself has improved in the new version, although I am running it on a Vista installation. The only real reason for this noticeable change is that the previous release would hang for a number of seconds when a virtual machine was started or stopped in Vista. It feels as though this is an issue that has been addressed in the beta, and so hopefully performance overall will have had the same attention.

Just a few shots of the new UI, first we have the login screen for the web-based management interface. My desktop is joined to the domain at my house, and the only account I could use to login was the builtin domain administrator account. Strange.

Next, the summary screen which shows some info about the host machine, which will be nice on a production server as it details the RAM usage. This will be something I look forward to using on my main server Zeus:

Finally, a shot of the only VM I have on this machine. In this case the VM is stopped, and it shows the hardware configured for the machine, and the 1×2.338GHz CPU looks promising - I could assign another!

That’s all I have on this for now, but if I find any more interesting stuff I’ll be sure to post an update. If you’re interested you can grab a copy from here: http://www.vmware.com/beta/server/.

OK, so seeing as the last post is about worrying errors reported by the RAID controller on my main server, Zeus, I’ve decided to do something about the heat that caused the errors in the first place.

The drive caddy in Zeus holds 4 drives, but they are far too close together, so I’ve spread them out somewhat, and added another fan, although it took some pursuation to get it in (by pursuation I mean using tinsnips to cut a hole in the front of the server). This is proving to work really well, now I just need to figure out how to get another exhaust fan in there somewhere.

Also, I have recabled the switch with colour-coded Cat5. We have red cables for the internet VLAN, yellow for the perimeter VLAN, and blue for the internal network. This has also been a good time to start wiring for gigabit, so I’ve ran the first cable to my desktop from the switch. All I need now is a few gigabic NICs and I’ll be all set.

Update: I’ve got some pictures up now. We have zeus with its new ghetto fan mod at the front, blowing nice cool air over a terabyte worth of data in the first two. Then the new switch and the lovely neat wiring job in the last one. On a side note, I’m really happy with the switch, it’s proving worth the cost after all. Looks pretty good as well sitting in the cabinet :). Now, if only I could get round to painting the inside of that server cupboard. It’s shameful!

Error occurred on Primary Master device on adapter 0. Primary Master - CDB 2a 00 01 58 aa 5d 00 00 01 00.

This is what I was greeted with in my inbox, as I started the day yesterday. It looks like at some time around 4am, the primary drive on my main server, Zeus, had been having a few problems to say the least. The drive gave about a hundred of the above errors, and then dropped off the RAID1 array. I opened up the case to see what was going on, and it would seem that heat was the killer, if anything. I shutdown the server, moved the drives around a bit to allow for better airflow, stuck an extra fan in, and booted it back up. The drive came back to life, and is rebuilding as I type this.

I am now, however, looking at a new SATA controller and 2×80GB Western Digital drives. Hopefully these will run cooler, faster, and allow for better airflow than their IDE counterparts.