This article covers the steps to configure a Watchguard Firebox to pass authentication traffic for PPTP VPN connections to a RADIUS server running on Windows Server. The first part of the document covers Fireware 10.2 and Windows 2008. Legacy technologies can be found at the bottom of the article.

Usage Scenario: You wish to have the Firebox terminate the VPN connection, but still pass the authentication through to your Active Directory server instead of using static Firebox user accounts.

Note: Fireware has Active Directory and LDAP authentication methods, but these cannot be used for PPTP VPN authentication as of version 10.2.12. These can be used with MUVPN, which requires IPSEC Client software to be loaded on the connecting workstation.

Benefits of having the firewall terminate a PPTP VPN:

·         It is not necessary to have more than one IP address on the Firebox’s external interface.

·         It is not necessary to set up 1:1 NAT, which would put your server on a different outgoing IP address from the rest of the network (this is a good thing from a “keep it simple” perspective).

·         You can reboot the server without dropping your VPN connection – you cannot authenticate while it is rebooting, but if you are already connected, you will stay connected.

·         PPTP tunnels terminated by the Firebox are generally faster and more reliable than when terminated by a Windows server.

·         It is not necessary to load any software on the connecting workstation; it’s built into Windows.

 

Configure the Firewall:

 

1.       Open the Policy Manager.

2.       Configure RADIUS Authentication:

a.       Click Setup -> Authentication -> Authentication Servers.

b.      Click the RADIUS tab.

c.       Check to enable the RADIUS server.

d.      Type the IP address of the Windows 2008 server and set the port to 1812.

e.      Type a “secret” and confirm it. Take note of this in your network documentation, as you will need it later to configure Windows 2008, and possibly even later still, when you change things on the network. Try to use a secure secret here.

f.        Click OK to close the Authentication Servers dialog. 

3.       Create the PPTP VPN Policy:

a.       Click VPN -> Mobile VPN -> PPTP.

b.      Check the box to Activate Mobile VPN with PPTP.

c.       Check the box to use RADIUS authentication.

d.      Require 128-bit Encryption (I think this is optional, but why would you?).

e.      Add an IP address pool.

Note: It would be a very good idea to create a DHCP exclusion matching this IP address pool, both to avoid IP conflicts due to DHCP, and to remind you that you have assigned these addresses when you go looking for an available static IP address later. If you have an IP address spreadsheet (hopefully you do), add it there as well. Documentation is key to an organized network.

f.        Click OK. 

4.       Create an Access Rule to allow VPN traffic:

a.       Click Edit -> Add Policy.

b.      Expand Packet Filters and double-click the “Any” filter.

c.       Change the name to “Any-RUVPN” (or something else that is descriptive to you).

d.      Remove “Any-Trusted” from the “From” area.

e.      Click Add-> Add User, select type “PPTP” and “Group”, double-click PPTP-Users, and click OK.

f.        Click Add-> Add other -> Network IP, add your internal network subnet, and click OK -> OK.

g.       Remove “Any-External” from the “To” area.

h.      Click Add-> Add other -> Network IP, add your internal network subnet, and click OK -> OK.

i.         Click Add-> Add User, select type “PPTP” and “Group”, double-click PPTP-Users, and click OK.

Note: We have just created a bi-directional rule that allow traffic both directions over the PPTP VPN. Your rule should have “PPTP-Users” and your internal subnet in both the “From” and the “To” areas.

j.        Click OK to close the policy properties dialog. 

5.       (Important!) Configure DNS on the Firebox:

a.       Click Network -> Configuration and go to the WINS/DNS tab.

b.      Enter the DNS servers for your network.

Note: The DNS settings are important for your VPN client to obtain the DNS server automatically from the firewall when the VPN connects. Unfortunately, as of Fireware 10.2, the DNS suffix is not passed to the VPN client, so you will need to include that in the VPN connection’s advanced properties on the workstation.

6.       Upload your config to your firewall. 

Configure Windows 2008:

1.       Prerequisites:

a.       Network Policy and Access Services

b.      Windows Firewall disabled or configured to allow RADIUS traffic on port 1812. 

2.       Ensure that NPS is installed and started. 

3.       Create a Security Group:

a.       Create a security Group on your AD domain controller with a name that is descriptive to you (VPNUsers, for example) and populate it with users who will have VPN access. 

4.       Open the Server Manager. 

5.       Tell Windows about the RADIUS Client:

a.       Expand Roles -> Network Policy and Access Services -> NPS (Local) -> RADIUS Clients and Servers, and select RADIUS Clients.

b.      Right-Click RADIUS Clients and select New RADIUS Client.

c.       Check the box to enable the RADIUS Client.

d.      Type a friendly name (Firebox) for the RADIUS Client.

e.      Add the IP address of the Firebox.

f.        Select RADIUS Standard from the Vendor Name list.

g.       Choose the “Manual” radio button.

h.      Type and confirm the “secret” you entered into the Firebox config in the “Configure the Firebox” section.

i.         Make sure both checkboxes at the bottom o the dialog are unchecked and click OK. 

6.       Configure a RADIUS Authentication Policy:

a.       Expand Roles -> Network Policy and Access Services -> NPS (Local) -> Policies -> Network Policies.

b.      Right-Click Network Policies and select New.

c.       Type a Policy name that will be descriptive to you (RUVPN Connections, for example).

d.      Leave the “Type of network access server” set to “Unspecified” and click Next.

e.      Click the Add button and double-click “Windows Groups” in the Conditions list.

f.        Click the Add Groups button and type or search for the VPN users group you created earlier.

g.       Click OK -> OK, which should bring you back to the Specify Conditions dialog.

h.      Click the Next button to get to the Specify Access Permission dialog.

i.         Leave “Access granted” selected and click Next.

j.        Ensure that MS-CHAP-v2 and MS-CHAP are selected, and click Next.

k.       Click Next again without configuring any constraints.

l.         In the left Windows pane, select Standard under RADIUS Attributes.

m.    Remove any existing attributes and click Add.

n.      Double-click Filter-ID.

o.      Click the Add button.

p.      Type “PPTP-Users” (case sensitive) into the “String” field and click OK.

q.      Click OK and Close to get back to the Configure Settings dialog.

r.        Select Encryption under Routing and Remote Access, and uncheck “No Encryption”.

s.       Click Next -> Finish.

t.        Right-click you new policy and select “Move Up” repeatedly until it is first in the list.

Test your configuration:

1.       Set up a workstation outside the firewall with PPTP VPN.

2.       Connect to the VPN with a user who exists in the VPN users group you created in AD.

3.       Once the VPN is running, test access to network resources.

Note: It is possible to be connected to the VPN, but still have no resource access if you did not configure the access policy properly, so be sure to test this.

 

Update:

If you have an older Firebox running WSM 7.x, and wish to use PPTP terminated by the firewall, with RADIUS authenticated by a Windows 2008 server, use these instructions for the firewall side:

Note: You will need to adjust the policy in NPS on the Windows 2008 server to use “pptp_users” instead of “PPTP-Users”. This changed between WSM and Fireware.

 

Configure a legacy Firebox (WSM 7.x) for Remote User PPTP:

1.       Open Policy Manager and select Setup -> Firewall Authentication.

2.       Select the radio button for RADIUS Server -> OK -> OK.

3.       Enter the IP address of the Windows 2000 server running IAS.

4.       Change the Port number to 1812 and enter your shared secret -> OK

5.       Click Network -> Remote User -> PPTP tab.

6.       Check the checkboxes for Activate Remote User and Use Radius Authentication.

7.       Click the Add button, select Host IP Address and enter the first IP address you allocated for use by the Firebox -> OK.

8.       Repeat this until all of your allocated IP addresses have been entered.

Note: You can copy/paste into the IP address field.

Note: You may wish to enable logging here if you have any difficulty getting this to work.

9.       Click OK.

 

Configure a legacy Firebox Access Rule for RUVPN:

1.       Add a service to allow traffic from VPN Users:

a.       Click Edit -> Add Service. Expand Packet Filters and select “Any”.

b.      Click the Add button. Change the name to “Any-RUVPN”.

Note: If you change this name, I recommend against using spaces.

c.       On the Incoming tab, select “Enabled and Allowed” from the selection list.

d.      Click the Add button in the “From” area and add the “pptp_users” group.

Note: If the “pptp_users” group is not available to be selected here, you can click “Add other”, drop down and select “Radius User or Group” and type pptp_users in. I had to do this with a Firebox. Once I had uploaded the config and firmware to the firebox, then pulled down a fresh config file from the firebox, the pptp_users that I had typed in became the special Firebox group and took on the icon with the two head with a red thing behind them, indicating that it recognized the special group. Your mileage may vary.

e.      Click the Add button in the “To” area and add “Trusted”.

f.        Go to the Outgoing tab.

g.       Add “Trusted” to the “From” area and “pptp_users” to the “To” area.

h.      Finish the rule and upload the configuration to the Firebox.

 

 

 

If you have a Windows 2003 server and wish to use IAS for RADIUS authentication for a Watchguard Firebox, here are the steps:

Install and Configure IAS on Windows 2003:

 

Note: You must either disable SMB Signing or use Firebox Software version 7.30-B2938 or later!

 

1.       In Add/Remove programs -> Windows Components -> Networking Services, check “Internet Authentication Service” and finish the wizard.

2.       Open the Services applet and stop, then restart the IAS service. Refresh the screen and ensure that the service continues to show “running” status. Some applications (the Symantec antivirus management console, for example) interfere with IAS by using port 1812. If this is the case you will need to configure IAS on a different server.

3.       Open Administrative Tools -> Internet Authentication Service and select Radius Clients in the left pane.

4.       Click Action -> New Radius Client. Enter “Firebox” for the friendly name.

Note: If you change this name, I recommend against using spaces or non-alpha characters.

5.       Enter the Trusted IP address of the Firebox for the Client Address and click Next.

6.       Verify that RADIUS Standard is the selected protocol.

7.       Enter and confirm a “shared secret” of your choice.

Note: I recommend Uppercase, Lowercase, and Numbers - but not non-alpha characters.

8.       Verify that RADIUS Standard is the selected Client-Vendor.

9.       Verify that the box for “Request must contain the Message Authenticator attribute” is NOT checked, and click Finish.

10.   Select Remote Access Policies and click Action -> New Remote Access Policy.

11.   Select the option for “Set up a custom policy”.

12.   Enter VPNUsers for the friendly name of the policy.

Note: If you change this name, I recommend against using spaces or non-alpha characters.

13.   Click Next -> Add -> select Windows-Groups -> Add -> Add -> select your VPNUsers group -> OK -> OK -> Next.

14.   Select the radio button for “Grant remote access permission” -> Next.

15.   Click the Edit Profile button -> Authentication tab.

16.   Verify that the checkboxes for “Microsoft Encrypted Authentication version 2 (MS-CHAP v2)” and MS-CHAP are checked.

17.   Go to the Encryption Tab and clear the check box next to “No Encryption”.

18.   Click the Advanced tab and remove “Framed-Protocol” and “Service-Type”.

19.   Click Add -> Filter-Id -> Add -> verify that “string” is selected and type “pptp_users” into the attribute field.

Note: For Fireware Pro 8.2 the string must be set to “PPTP-Users” (case sensitive).

Note: Other documentation may suggest that you type something else here, like your group name. DON’T. The Firebox wants to see “pptp_users” or “PPTP-Users” in this attribute, just as it is typed here - lowercase, underscore or hyphen and all.

20.   Click whatever combination of OK, Next, and/or Finish is required to complete the config. If it prompts you to view help topics, say no.

 

Tags: Firebox, Fireware, Network Policy Server, PPTP, RADIUS, Watchguard

What’s a USN Rollback? That’s when you’ve restored an Active Directory DC in a multiple DC environment using a method that is not Active-Directory Aware. Examples include Ghost images, VMware or Hyper-V snapshots, or other imaging or volume-level restore methods.

Why is that a problem? A very good detailed explanation is available here, but the basic idea is that AD keeps track of which servers it has replicated with and when, and if a DC is rolled back in a way that is not compatible with the record-keeping, the affected DC will disabled inbound and outbound replication, and refuse to replicate with the other DCs.

Here’s a related article by the same author as the above post, which led me to my solution this evening. My article expands on the second option provided, but goes into the mechanics of it, and the associated difficulties.

According to Microsoft’s Knowledge Base article on the subject, recovering from this situation entails forcibly demoting the DC, cleaning up the AD, and then (optionally) promoting it again. If the DC in question has no other roles, or just a couple of basic ones such as a print server, this might be the best way to go, if you’re familiar with such things as seizing FSMO roles and performing metadata cleanup in Active Directory after an unsuccessful DC demotion.

** Update: Read on for more details about how this all works, but make sure you check the update at the bottom of the article for the easier method I successfully tested!

However, if you’re not familiar with these things, or you have other applications on the server which might be affected (IIS, in particular, is very sensitive to the permissions changes associated with DC promotion), this might create a very large amount of havoc on your server.

Your saving grace, if you have one, is a System State backup from before the USN rollback occurred. If you don’t have a backup of JUST the System State, perhaps you can restore an entire image to another server, boot it, and create one.

If you have or can create one of these, your solution becomes much simpler. You just need to boot your server in Directory Services Restore Mode, restore the System State, DO NOT mark any part of your restore as authoritative, and reboot.

After the reboot, you might need to remove the flags AD has set, which have disabled inbound and outbound replications. The commands for this are:

repadmin /options [YourServerName] -disable_inbound_repl
repadmin /options [YourServerName] -disable_outbound_repl

Note: This looks like you are disabling replication, but what you are actually doing is putting a minus sign (-) before the disable option, which enables it. I know, it’s counter-intuitive, but trust me on this one - or go check the syntax yourself.

Of course, you need the Support Tools installed to get the repadmin utility. Once you run those commands, your server will start replicating again, and the more up-to-date DC(s) will override the old, out of date information your USN Rollback victim was holding onto.

There are some extra difficulties associated with the above plan:
1. If you have to restore a server image to create that System State backup, and you restore to different hardware, things could get a little messy. Is it messier than demoting, seizing FSMO roles, performing metadata cleanup, promoting, and cleaning up the fallout from your installed apps? You’ll have to decide on that one.

2. This requires you having an extra server (or two, if you want to restore more than one DC to create a stable lab environment from which to back up the System State) laying around. Do you have those resources available?

I was facing this issue today, and all of the above became MUCH simpler for me when I realized I could use the Doyenz Test Lab to sort all of this out. I did NOT have a System State backup from before the USN Rollback, but I HAVE been running backups into the Doyenz system since before the problem began.

Here is what I did:
1. Created a backup of the System State

a. Restored a copy of the affected server in the Doyenz Test Lab. I specifically restored from the date BEFORE the USN Rollback happened. It was easy to find this by looking at the date of the last successful replication with repadmin on the affected server.
b. Performed a System State backup using NTBackup (you can do this with WBAdmin on Windows 2008).
c. Zipped the backup file and sent to an FTP server.
d. Shut down the restored server.

2. Performed a test run to make sure this was going to work, without affecting the live servers.

a. Using the Doyenz Portal, I select last night’s backup and restored it for both servers.
b. I booted the primary DC (the one with the FSMO roles) first.
c. Attached the second (USN Rollback victim) server to the first one in the Lab, and booted it.
d. Pulled the System State backup down from the FTP site onto the affected server.
e. Rebooted the affected server into Directory Services Restore Mode.
f. Restored the System State on the affected server.
g. Rebooted the affected into Normal Mode.
h. Used the repadmin commands to remove the replication blocks.
i. Forced replication using AD Sites and Services.

3. Verified successful replication.

a. Created a user account on one DC in the Test Lab, forced replication, and checked for the account on the other DC.
b. Deleted the user account on the other DC, and checked it on the first DC.

4. Tested the touchy sensitive web applications that are running on the affected server.

5. Shut down the servers in the test lab.

After this successful test, I notified the users of pending late-night downtime, and repeated the above steps, this time on the live, production server and with great confidence of the outcome. Sure enough, I restored the AD replication functionality of the server with minimal downtime, without crossing my fingers, holding my breath, and hoping against hope that it would work and not trash the server.

What is more, since the production server is a virtual server, and I have VPN access to the virtual host, I was able to perform the entire operation from my home office, 30 miles away. I didn’t swap any tapes, set up any lab hardware, or drive to the server site late at night. I did the whole thing in comfortable clothes with a 2-liter bottle of Ruby Red Squirt, Winamp playing “Save Me” by Queen, and my devoted cat purring on my lap.

What could be better than that?

Update: It was very handy to be able to do the above scenario, but what is even handier is that I was able to find a significantly simpler method. So much simpler, I wonder why it did not occur to me sooner, and why Microsoft doesn’t have this listed in their KB article.

I set this problem up in a lab scenario again, and this time rather than do a complicated restore of an earlier version of the machine, I simply:

• Performed a System State backup of the machine (in its broken, non-replicating condition).
• Booted it into Directory Services Restore Mode.
• Restored the System State backup, carefully NOT selecting the option to make it authoritative.
• Rebooted, and ran the above repadmin commands to re-enable replication.

After that, I was able to trigger another replication, and it worked just fine.

Tags: Active Directory, Restore, Snapshot, System State

Summary:
Triggered by an excessive heat wave, I used the built-in Windows Backup to do a test restore of my production virtual servers from their usual VMware ESXi host to a smaller, more portable machine that lives in an air-conditioned room. The servers will run there until the heat wave dissipates, whereupon I will reverse the procedure and move them back to their usual home.

The restore process was incredibly easy. This is a demonstration of how portable and flexible virtual servers are, and how well the built-in Windows Backup works with virtualization.

I can now say with a high level of confidence that virtual servers, backed up with a local VSS-based disk backup solution, and coupled with an offsite backup solution, is a great way to go. My scenario was a simple problem with a simple solution, but this power and flexibility can easily be applied in many different situations.

The Full Story:
If you live in the Western Washington area, you know we’re having a crazy heat wave.

Many businesses have servers tucked away in closets, kitchen areas, and other little nooks and crannies, without air conditioning. Mine is one of them. I strongly recommend air conditioning to my customers, and it is with some embarrassment that I admit that I have not implemented it myself - but I have never needed it before. My company’s servers are in a steel enclosure in a 675 square foot garage. Usually it stays quite cool, verified by the thermal monitoring unit attached to my battery backup system. If the temperature gets too high, the battery backup sends a shutdown command to the servers so they are not damaged by the heat.

Several of my customers have had thermal shutdown issues the last few days. Today it was my turn. I happened to be sitting at my workstation when the e-mail arrived, telling me that I had 3 minutes to correct the situation before things started shutting down.

I started by logging into the battery backup unit and adjusting the threshold up a few degrees to give me time to work. Next I walked down to the server rack and opened its door to allow more air flow to the servers. The thermal monitor is just inside the door, right next to the air intake holes in the front of the server. The third step I took was to shut down one of the servers in the rack - a virtual server running Windows Home Server, which backs up my workstations. Since I don’t store data on workstations, it’s OK to go a few days without backing them up.

Back in my air-conditioned office, I logged into the battery backup management web page and saw that it had gone up to 91 degrees while I was working, but was now back to 90. I watched it for a few minutes. It stayed at 90. Still too hot.

Sitting back and thinking about my options, I considered fans - but the entire room was very hot. Fans would only push the hot air around, and I’ve heard horror stories and seen pictures of server rooms which had burned down due to electrical fires starting from cheap fans that weren’t designed for a 24/7 duty cycle.

I considered moving the server to my office - but the server is very noisy, being a rack-mount server with small fans moving very quickly. However, my servers are virtual, running on VMware ESXi, so they should be very portable…        …and an idea was formed.

One of the great benefits of virtualization is that you can put your virtual machine on any hardware that is supported by the host operating system, which in my case is VMware ESXi. That makes backup and restore very simple. You don’t have to be concerned with hard disk controller drivers and other such obstacles to a smooth restore operation.

I’ve been evangelizing these virtues for over a year now, and using the technology myself. I decided to use this unfortunate heat wave as an opportunity to perform a real-world test of the technology I have been talking about. I decided to do a last-minute backup of my server, move the backup device to a smaller, quieter machine in my office, and restore the backup. I would run it in my office until temperatures reach sane levels again, and then reverse the procedure.

I warned the users that the server was going down for a while. I stopped the incoming e-mail service, and forced a “backup now” on the SBS 2008 and Windows 2008 servers that form my infrastructure. That took about 1/2 hour. I am using the built-in Windows Backup, and it is performing disk-based incremental backups. Then I shut down the “guest” operating systems, and finally shut down the host server.

Again I walked down to the server rack and disconnected the external hard disk that I store my local backups on. It was nearly hot enough to burn my fingers. I carried it up to my office and plugged it into the generic white-box server ($800) that I use to run lab experiments. This machine would also make an excellent loaner ESXi server if one of my customers experienced a server failure. It has a single quad-core 2.5GHz CPU, 8GB RAM, and 1.5 TB of disk space.

I attached the USB stick that boots VMware ESXi on that host, booted it up, and configured its networking (2 minutes).

Next step, I created two guest virtual machines with the same disk sizes as the machines I was going to restore. I had to allocate less memory, so the servers might run a little slower. Then I attached the virtual disks on the backup device to the appropriate VMs, and finally mapped the SBS2008 and Windows 2008 DVDs to the new virtual machines and configured them to boot from DVD.

I booted up the SBS2008 server first. It booted from DVD, and I used the menus on the DVD to start a Full Computer Restore, using the backups that it found automatically when it searched the attached disks. I chose the correct date/time of the backup to restore, verified that all of the volumes were present, and told it to begin.

I didn’t have to flounder around looking for hard disk controller drivers, making floppy disks or putting drivers on USB. I set to work on the second server, which is less critical to my business, and had similar results with that one. Not wanting to cause the first restore to slow down, I brought the second server to the final prompt to begin the restore, and waited for the first one to complete.

The restore was the easiest full-server restore I have ever done, with the best results. After the restore, I booted the server, and it was off and running without a backward glance.

The first server, which runs 90% of my business, was restored and running less than 2 hours of shutting down for the move. A backup queuing mail service had received and stored my e-mail while it was down, so I didn’t miss a single message. The second server, running my blog site, followed soon after.

I did have three very small hiccups:
1. Windows detected the hardware change (probably the CPU chip) and required re-activation, but it worked automatically – two mouse clicks and a few seconds took care of it.
2. Because I forgot to set the date/time properly on the destination ESXi host, my SBS2008 server’s clock got set wrong and that caused authentication problems for a few minutes until I figured out what was going on and corrected it.
3. The DHCP Server service on my SBS did not start because I was running an open-source DHCP server during the downtime to keep everything connected to the network. I just had to stop the one and start the other.

Compared with the kind of difficulties I would normally expect with this kind of full server restore to different hardware, this was a piece of cake.

I can now say with a high level of confidence that virtual servers, backed up with a local VSS-based disk backup solution, coupled with an offsite backup solution, is a great way to go. My scenario was a simple problem with a simple solution, but this power and flexibility can easily be applied in many different situations.

Tags: backup, ESXi, SBS 2008, Virtualization

Much thanks to Mark B. for the catchy phrase in the title!

SBS 2008, by default, enables some security measures on mobile devies hiwhc use ActiveSync. These security measures are, of course, entirely appropriate for keeping valuable information on NSA employees’ handheld devices secure.

OK, OK, these measures might even be appropriate for the medical field, legal, banking, and a number of other fields.

However, you may have a client who does not want/need/like them. They may become particularly grumpy if these policies are suddenly pushed down to their handheld without warning after an SBS 2008 upgrade.

Here’s how to find and adjust them:

1. Open Exchange Management Shell.
2. Expand Organization Configuration.
3. Select Client Access.
4. Right-click the Windows SBS Mobile Mailbox Policy object and click Properties.
5. General Tab:
   • By default, “Allow non-provisionable devices” is checked, so that’s OK.
6. Password Tab:
   • There are a number of settings in here to adjust, most notably whether or not a password is required on the device, how many characters it must be, and whether it can be “simple” or not. The context-sensitive help is amazingly unhelpful regarding what a “simple” password is, but if you click the link near the bottom labeled “Understanding Exchange ActiveSync Mailbox Policies”, you get a better description, albeit not a comprehensive one. It simply (pun intended) says “This setting enables or disables the ability to use a simple password such as 1234. the default value is $true.”
7. Sync Settings Tab:
   • Another marvelously well-thought-out move by Microsoft is to set the default to include ALL past Calendar and E-Mail items, and allow attachments. Rumor has it they took money from flash memory card manufacturers for that setting.
   • On my Windows Mobile 5 device, I seem to be able to override these settings, and they do not get set back during the next sync. YMMV.

Alternatively, you could simply delete the entire policy. I suspect that if you did this after the settings were pushed out, the handhelds would not be able to be adjusted until they were reset to default, or until you created a new policy with all settings unchecked or something similar.

Probably the best solution is prevention - disable HTTPS through the firewall during the migration until you have had a chance to adjust these settings or remove the policy.

Tags: Activesync, Mobile Mailbox Policy, SBS 2008, Security

I loaded drivers on my SBS 2008 server for the HP Color Laserjet 2600n printer.

On my 32-bit XP workstation, I connected to the server via UNC path, right-clicked the printer, and told it to connect. This is usually sufficient to load the driver, and give access to the printer.

The symptom:
This time, although it connected successfully and I had a printer object for it, whenever I tried to print to it, Windows wanted to send a love note to Microsoft, and when I closed that dialog, Explorer crashed and restarted.

This works fine on the Vista computers in my network.

I right-clicked on the printer object and tried to get to Properties. Windows XP told me that I needed to install a driver for the printer. I gave it the proper driver and it showed me the properties. I tried printing again, and BANG! another Explorer crash. It turns out that no matter how many times I gave it that driver, it still thought it did not have the driver.

I tried a variety of different ways, from loading the drivers at the local console of the server, connecting from Windows XP and Vista workstations to \\server\printers and loading it there, across the network. I downloaded new drivers from HP and tried those.

Since this is a 2600n and has a JetDirect card, I realize that I could easily have created a port on the XP workstation and mapped directly to the printer instead of going through the server, but I was getting stubborn.

Finally, I tried something a little different.

I created a new port on the XP workstation. I used the “Local Port” option, but when it asked for a port name, I typed \\server\printersharename in the “Enter a port name:” field.

It works like a charm. The icon even looks like a network printer icon instead of a local one. I edited the printer name to be <printername> on <server> to make it look just like the other network printers, and I can manage its print jobs centrally.

There is one drawback to this approach: Terminal Services does not map back the printer when I do this. However, since it is networked printer on the same LAN with the server, and I do not often use this feature when connecting to other networks, it’s not an issue for me.

Tags: Laserjet 2600N, SBS 2008, Windows XP