How come a “printing system” has to be a 300mb download or CD ordered by mail? I’m all for having that as an OPTION, but for servers and for shared printers, all I need is a driver and that can probably still fit on a floppy disk… if my computers and servers still had floppy drives, but that’s another post!

I already posted about 32-bit printing in an increasingly 64-bit world, and my medium-term solution for that was to stand up a 32-bit Windows Server 2008 VM and use that as a print server.

This post is the next step: printer drivers. Specifically migrating printer drivers from one server to another. For the small amount of printers I have to manage (three printers and two plotters in this office) or even the amount of printers (queues) at my last job (about 40) it’s not so difficult to do it manually. I did just that when we moved into a new building at my last job and stood up a VM just for print queues. Pretty straightforward, really: download the latest printer drivers from the manufacturers web site, unpack them to a network location, Add Printer from the printers window/control panel, new local port, new TCP/IP port, punch in the printer’s IP address, have disk, browse, click, select… done. 40 times. A wee bit time consuming. For this migration here I only had the six, so it should be even easier. But what if the newer version of a printer driver doesn’t work properly with your as-configured software?

That’s where I am right now. We have a Kyocera CM3232 photocopier/printer/scanner/fax. It’s a big one with it’s own onboard cost accounting and “proper” network scanning & faxing. It does color and black & white and prints on up to 11x17 paper (although not borderless printing). On the old OLD server, printing CAD drawings from Acrobat Reader plots properly. On the new-old server, it didn’t. There were some weird issues where drawings would not be rotated based on the settings you selected in Acrobat, but if you left Acrobat’s settings on Portrait but clicked Advanced Print Properties and changed it to landscape on the driver settings, it would work. Not very intuitive and sure to be the cause of plenty of helpdesk calls.

We tried a different driver, we tried an old driver from a CD that presumably came with the printer and nothing seemed to work. In the end, I re-pointed everyone’s printers back to the old server and removed the queues from the new-old server… but that old server isn’t going to last much longer and it’s not easy to find parts for an old IBM X-series Pentium III tower server, and having a single Windows 2000 Server in the mix is also holding the rest of the network back.

The new-old server blew up in December. No big deal for printing, but HUGE FUCKING DEAL for everything else. I managed to get it up and running again, Frankenstein-style and convert it to a virtual machine before shutting it down for good and sending the carcass to the recycling center.

That new one is here, and one of it’s roles is hosting a Windows Server 2008 32-bit VM for print queues, so I’m back to trying to make the new server play nice and plot drawings properly… the Windows Server 2008 driver for the copier is doing the same weird things the 2003 driver was doing… If only there was a way to migrate those queues, drivers and ports over to a new server… oh wait! there is! Hallelujah I think I hear a choir of angels singi—wait, what? that only really works for moving from NT4 to 2000? It wasn’t really updated for 2003, 2003 R2 or 2008? The tool has been retired? Oh good grief!

Fortunately there’s a new version built-in to Server 2008 and Server 2008 R2. You access it from Print Management Administrative Tool, as opposed to the Printers control panel applet. From there you can add the old server as a network print server, right-click it and export printers to a file… then right-click your new server and import printers from a file. I’m in the process of doing that right now, and will be testing it with CAD drawings later today. Fingers crossed.

(or a 64-bit domain anyway)

Hooray! 32-bit is dead! Long live 64-bit! … … … not exactly.

While there are more 64-bit machines out there now than there were a year ago and tons more than a few years ago, a lot of businesses are still firmly entrenched in 32-bit Windows XP. I know we are.

We’re a pretty good example of someone who SHOULD make the leap to a 64-bit OS. If there’s one segment of the market that supports 64-bit and is extremely memory-hungry, it’s CAD work. And we’re all about CAD work. I’ve recently upgraded all the computers to 4GB of RAM and standardized them on one video card (nVidia Quadro FX 580 512MB), they’re not taking full advantage of that 4GB of memory because the 32-bit XP Professional can’t address it all. Even with the /3GB switch in the win.ini file, that just means acad.exe can use more than the 2GB limit per process… but I’m getting off topic.

When I started here in Q4 of 2008, I took one look at the “datacenter” and my jaw dropped. The main file server was an old IBM x-server with a Pentium III and a whopping 768mb of RAM and a couple 160GB hard drives in RAID1. The web/intranet server was an even older one. Both were running Windows Server 2000. The Domain Controller was newer, it at least had Windows Server 2003 on it, but it was consumer-grade, non-redundant components in a 2U rackmounted case.

Before Christmas rolled around I had replaced the ancient file server with a pair of Supermicro SuperServers with Quad-core Xeons, 4GB of RAM and 5x1TB SATA2 drives in RAID5 configurations and added an LTO-4 tape backup to the mix. Between Christmas and New Years, the web server died so I replaced that one with another Supermicro identical to the first two, but with just 2x250 and 2x500GB drives in RAID1. All of these servers were running Windows Server 2008 Standard x64.

This led me to a major problem: I was able to install printer drivers for each of the printers on the servers themselves, but with the 64-bit drivers. Client computers (XP Pro SP2 x86) tried to connect and failed because they couldn’t use the 64-bit drivers. In the old days, you could go to the sharing tab of the printer properties and click “Additional Drivers” and that was pretty much that, but cross-architecture is a little more squirrelly, and the solution is counter-intuitive.

Here is how to provide a 32-bit driver in the Additional Drivers page on a 64-bit server:

Step 1: Install the 64-bit driver on the server itself and make sure that you can print.

Step 2: On a 32-bit client (I used XP Pro) download and unpack the drivers for the desired printer (in my case it was an HP Laserjet 4600).

Step 3: Open Windows Explorer and navigate to your printer share: \\64-bit_server\ and then double-click Printers and Faxes.

Step 4: Right-click the desired printer and  select Connect. It will do it’s thing and then Uh-Oh.. where’s the driver? It will ask you to provide a driver. Browse to your local folder where you’ve stashed the .inf files for the printer and let it install. Print a test page to make sure it’s working on your computer.

Step 5: On the server, right-click the printer you just added and select Properties. Click the Sharing tab, and then click the “Additional Drivers” button. Click to check the “x86” button for 2000/XP and click OK. The server will then request the x86 versions of the files FROM your local workstation and upload them TO the server.

This is the back-asswards part that tripped me up. You’re actually uploading the driver TO the server so it’s able to them DOWNLOAD it to OTHER x86 clients that request it.

Step 6: Click ok, ok, ok, all the way back out and you should be good to go.

Dingle Dangle Dongle… I’m Robert Goulet! doo da deee da dabba doooo

Seriously. It’s 2010. Who still uses Parallel port hardware locks? For that matter WHO STILL USES PARALLEL PORTS?

One of our (I thought older) software packages we use where I work has a parallel port dongle. Dongle not there? No design software for you!

What happens when you upgrade someone off some ancient AMD Athlon to a newer computer from the last few years? one that doesn’t even have a parallel port on the back anymore? Well… not much! But wait! there’s USB! People still make and use USB dongles! We’ll just ask the vendor to replace it! What? No? You don’t have anymore? But the software is still supported isn’t it? Yes? Well what happens if someone loses their dongle? What if there’s a fire? They’re SOL? Maybe? Who knows.

Eventually someone got back to us and said that since version 10.1 you don’t NEED the dongle anymore. We’re on 10.7 so we should be OK without it… right? No?

OH, you mean we have to completely uninstall the whole thing, then re-install from the non-customized version on the DVD, and then apply eight service packs plus our customizations? Sure no problem! I’ll get right on that! I didn’t have anything to do all day, nor did the operator who’s computer is out of commission all day now, either!

WSUS is a pretty cool piece of software. Basically it acts as a “Windows Update” server for your network. Rather than have all your computers download the same updates each from Windows Update, your WSUS server dowloads it once and then distributes it to all the computers that need it over your LAN connection which is much speedier than 99.9% of the internet connections out there. It also gives you a single place to go to and approve updates. Heard bad things about an update? Don’t approve it for installation and it won’t make it’s way onto any of your machines until you do (or they release an update to supersede it). A nice solution for small and medium sized networks.

You can extend it out to different geographical sites, too. Using a downstream replica server, you can have your server in another office “take it’s lead” from your server and either download the updates from you, or (and this is cool) only download updates that you’ve approved on your server from Microsoft’s servers. If you have a metered or slow connection between the offices, this is a great solution. You still only have one place to approve/deny updates, but you don’t chew up bandwidth pushing the updates from Office A to Office B.

This is the setup that I have. I have six offices (and two satellite offices but they’re not part of the corporate network) and aside from head office, there’s only one server in each location. These servers are Domain Controllers (for logins & resource management), WSUS downstream replicas for Windows Updates, and File & Print servers for that office.

WSUS uses Group Policy Objects (GPOs) to configure your clients (XP, Vista, Windows 7, Server 2003, 2003 R2, 2008, 2008 R2) to look at your own server for Windows Updates, as well as how often to check, and whether or not to allow the users to defer a restart so as not to interrupt them in the middle of something. Here’s where my setup gets trickxy.

I have a GPO called WSUS-Office A that I apply to the Active Directory Site called “Office A” so anyone who logs in at Office A will have their Windows Update Automatic Updates (WUAU) client pointed at the local server. Other offices have their own GPO assigned to their sites to keep everyone looking at the closest/fastest server/connection.

The hitch I ran into today was with my servers because of the Out Of Bound security bulletin released by Microsoft today for MS010-002. Because of the Big Scary Crisis surrounding it, and the fact that it was listed as Critical and affecting IE 6, IE7 and IE8 on Windows 2000 SP4 all the way up to Windows Server 2008 R2, I manually synchronized my WSUS with Microsoft this morning, downloaded the updates and approved them.

I also did a dirty thing to my users: I set a deadline in WSUS of noon today for the installation. That means that they’ll be notified of the download, and if they click the little yellow shield it will install it and then say “Time to restart!” but they can click Restart Later. Once the deadline passes, however, they don’t have a choice. the window comes up and says “restart your computer or I’ll do it for you” and starts a 15 minute countdown timer. I don’t do it often, so they know that I only do it for “critical” updates. Plus I emailed everyone last night and told them it was happening and posted it on the Intranet as an announcement. This morning they all got a second email that it would happen shortly.

Where the patch wasn’t installed was on some of my servers. Some of them got the update, and some of them installed it and rebooted without warning (oops, but they were warned). I started looking into why some of the servers installed it and some didn’t. My first thought was that the Server 2003 servers did but the Server 2008 & R2 servers did not. I thought perhaps that the GPO didn’t apply to/configure the Windows 2008 clients, but that was wrong, too.

Finally I compared a 2008 virtual machine’s Windows Update screen (which wasn’t working) to a 2008 physical machine’s Windows Update screen (which was). The 2008 VM said “You receive updates: For Windows and other products from Microsoft Update” and the 2008 host said “You receive updates: Managed by your System Administrator” Further investigation into the registry (HKLM\Software\Policies\Microsoft\Windows\Windows Update\AU\) showed that the settings that were specified in the GPO were applied to the 2008 Host, but not the 2008 VM.

It then dawned on me that the difference between the two was the host was a member server and the VM was a domain controller. That led me to GPresult and Group Policy Modelling. Using the DC and Administrator accounts, the GPO (identified by a GUID rather than it’s name) that was applied to the site was denied application due to SOM (Scope of Management).

I expanded the forest folders and drilled down to the Domain Controllers OU and saw a blue exclamation mark on it. Blocked Inheritance. That meant that the Domain Controllers OU was going to not inherit any settings from GPOs ‘above’ it, including sites.

So my choices at this point are to remove the block and let everything apply to the DCs. Not a very good idea. There were three policies which would have applied to the DCs: the Default Domain Policy, Remote Desktop Policy and Office 2007 File Format Policy.

The Office 2007 File Format Policy is tame, all it does is make the default filetype for saving the Office 97-2003 compatible instead of the new .docx, .xlsx and .pptx formats. Remote Desktop Policy is equally benign. It’s denied to Domain Admins and auto-disconnects clients from Remote Desktop after 10 minutes of inactivity so it wouldn’t really apply anyway.

The Default Domain Policy had a fair amount of settings in it though: Firewall settings, password policies, that sort of thing which I don’t necessarily want to apply to my Domain Controllers.

SO, removing the Block Inheritance setting probably wouldn’t be a good idea.

The other thing I could do is apply the WSUS-Office A policy to the Domain Controllers OU. It would get around the Block Inheritance issue without applying the default domain policy to them, but it would also “point” each of my offices’ Domain Controllers back here over the slow, metered internet connection. Not ideal either.

The other thing I could do is copy each of the WSUS-OfficeX policies and then apply ALL of them to the Domain Controllers OU and use filtering to make sure that each office’s policy only applies to that office’s WSUS server. That doubles the amount of work I’d have to do if I changed one of the servers though, and if I forgot, it would mean that one of the Domain Controllers was pointing at a non-existing Update Server which could leave it unprotected/unpatched. Guh. Meh. Not ideal.

SO that’s where it stands now. I haven’t done anything yet. I’m remembering in the short term to manually check the DCs for Windows Updates until I can come up with a little more elegant solution to the GPO filtering situation.

(This is a crosspost from the Autodesk Discussion/forum website that I was participating in)

Since I started here 15 months ago, I've been wary of messing with NLM because I didn't understand it. I still don't know all of it, but I know a lot more thanks to Travis and the rest of the contributors NLM isn't as big of a scary monster as it was before! There were Group Policy entries in my domain that were specifying an environment variable for the local license server (distributed model) by IP address, and then the next biggest office as a secondary, and third biggest as tertiary--by IP address. So for example if you logged in to a computer in site A your environment variable would be ADSK_FLEX_LICENSE=@192.168.1.2;@192.168.2.2;@192.168.3.2 It worked, it was working, so I had no motivation to change it.

While checking some things out on Travis' suggestions, I changed it to a server name, so on my test computer in site C, the environment variable was ADSK_FLEX_LICENSE=@SiteC_server;@SiteA_Server;@SiteB_Server and it worked. I then changed all my environment variables to computer (NetBIOS) names.

That sorted out 4 of my 5 offices, just the 3rd one, Site C users were still grabbing licenses from sites other than their own. Further investigation showed that two of the users who were using the wrong license server hadn't logged out and back in for some time. (this prompted a quick meeting with the CAD Manager and the Sustainability Committee to make changes to inactivity timers and lock computers after one hour, log users off after 2 and go to system standby after 3 hours outside of regular business hours). When one of the problem users logged back in and started up AutoCAD, they did not get a no license error, but rather Autocad seemed to hang for a good 60-90 seconds with an hourglass... after that AutoCAD started up normally and she was on the correct license server. I did the same thing to the the other user and got similar results.

So in the end, there was some sort of networking issue (which is still undiagnosed) that was causing clients to skip over their own license server, but changing environment variables from IP address to NetBIOS names fixed the problem.

Later in 2010 we may implement other changes recommended here and move to a single/redundant license server instead of the distributed model.

First post of the new decade... maybe I won't let this place grow cobwebs in 2010 like I did in 2009 ;)

Back in January I posted a few articles about Windows 7 Beta and what it did to my laptop. It’s not Microsoft’s fault, it’s a combination of Dell and nVidia’s faults. It was the perfect storm: a known design flaw in the video card that affected a boatload of Dell, HP, Sony and Macintosh notebooks. On top of that was a poor design choice by Dell to not actually have contact between the overheating GPU chip and the copper heat pipe that’s supposed to cool it. On top of that was running a Beta OS. On top of that, using a pre-beta alpha-release of a driver for said beta os on a flawed laptop with a flawed GPU. A perfect storm.

While watching a video full-screen in Windows Media Player, the GPU overheated and blew up. Not only did it crash and blue screen and completely wipe out the running OS, but somehow it managed to overwrite the GPU BIOS! That shouldn’t be POSSIBLE, but it happened. The computer would boot up, just no screen. If I watched and waited for the hard drive to stop spinning away during bootup, typed my password and hit enter, it would log me in! I could HEAR the windows startup sound, but no video. No video on the external monitor or HDMI ports, either. Ultimately, because it was under warranty, Dell sent out a technician who replaced the whole motherboard, GPU included (although they replaced it with the same broke-ass GPU chip) so the story ended happily.

One of the things I noticed in the beta was the feedback system, which I used extensively (duh, that’s what betas are for) until I couldn’t. The big huge crash dump from the video card was never sent because after the motherboard was replaced, I was too scared to put the Windows 7 hard drive back in again. I figured I would wait until another beta (or RC) came out and hopefully there’d be a newer driver from nVidia available then, too.

On another note, there’s a way to use a clean, shiny penny to sandwich between the GPU and the heat pipe which drastically improves the transfer of heat to the heat pipe and can avoid just such an occurrence. (you can google nVidia GeForce 8400M GS Copper Mod to see for yourself). On the down side, doing so invalidates your warranty. I’ve refrained from doing it because of that, but when the warranty runs out, that’s on my to-do list for the very next day. Instead of doing a recall and replacing the bum chips (and the heat pipe while they were at it) Dell instead extended everyone’s warranty by 12 months, so if your laptop blows up (like mine did) you’re covered for an extra year.. but if it happens AGAIN after that period, you’ve got a dead laptop. No one else did anything better (HP, Sony, even Apple) so I don’t want to be TOO unfair and shit all over Dell only because they and their tech support have been very good to me over the years. No, really! :)

The Windows 7 RC is out today and will work (for free) until June 10th, 2010 or about 13 months. In the fine print is that starting 2 months before that, your computer will shut down every 2 hours as a warning sign that the expiration is imminent and that it’s time to get a properly licensed copy. Hopefully there’s an upgrade path so you can punch in a new product code and activate Windows without having to re-install with the release version. I can’t see myself NOT re-installing with 100% gold code, but I’m sure there will be people out there who have tweaked and modded their user profile and software set-up JUST SO and won’t relish the thought of starting over.

Happy Valentine’s Day, ladies. I hope you had a lovely day…

This Saturday it’s your turn to return the favor. That’s right, it’s been a month already! March 14th is Steak and BJ Day. It’s pretty simple… It’s steak… and a BJ!

www.steakandbjday.com for more details (pretty NSFW content)

We’ll be celebrating this year at Little Billy’s Steakhouse in Burnaby, but the jury is out on who’s picking up the tab! ;)