BFTech Impressions

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

Maybe your customer’s ISP blocks PPTP. Maybe your customer’s firewall doesn’t forward PPTP properly. Maybe you would prefer not to install an IPSEC VPN client on your workstations, especially one that requires expensive licensing.

OpenVPN may be a good option for you.

I experimented with this today, using its most basic form. It wasn’t difficult to set up, and does the job well enough. You can run a VPN over a UDP or TCP port, which you can easilty forward through most firewalls without having to worry about PPTP/GRE compatibility issues.

I tested it on Windows Server 2003 with an XP client. Both were 32-bit. However, it claims to work on 64-bit Vista, so should work on SBS2008 as well.

1.       Download the software from here (command-line only) or here (GUI version). The first one is entirely command-line. The second one includes an icon in the system tray to control the VPN.

2.       Install the app on both the server and the client computer.

3.       Generate a static key by typing the following at a command prompt: openvpn –genkey –secret “c:\program files\openvpn\config\static.key “

This puts a file called static.key in the config folder. You can, of course, go for a more complicated config with dynamic keys, but for the purposes of my initial test, I went with a static key. Copy this key to the c:\program files\openvpn\config folder on both the client and the server.

4.       Create a text file called vpnserver.ovpn in the c:\program files\openvpn\config folder, and populate it with the following:

dev tun
ifconfig 10.8.0.1 10.8.0.2
secret static.key

In this example, 10.8.0.1 will be the IP address the server will use, and 10.8.0.2 will be the IP address of the client side of the VPN.

5.       Create a text file called vpnclient.ovpn in the c:\program files\openvpn\config folder, and populate it with the following:

Remote 1.2.3.4

dev tun
ifconfig 10.8.0.2 10.8.0.1
secret static.key

In this example, 1.2.3.4 is the external IP address of the NAT device that will forward the traffic to  the OpenVPN server. You can use an FQDN here if you want.

Note that the IP addresses are reversed in the “ifconfig” line.

6.       Configure the NAT device to forward UDP port 1194 (configurable) to the OpenVPN server and make sure the server’s default gateway is set to the inside of the NAT device. (UDP 1194 is the default, but you can use another if you like.)

7.       At a command prompt on the server, execute “openvpn vpnserver.ovpn” or use the GUI icon in the system tray to start the VPN server.

8.       At a command prompt on the client, execute “openvpn vpnclient.ovpn” or use the GUI icon in the system tray to start the VPN client.

The two should now connect to each other.

This is the simplest implementation of this VPN software. It can also open the entire local subnet of the OpenVPN server to the client (I tested this). You can set up dynamic keys, user accounts, etc with the more advanced options.

Links:

The Main How-To.

The Mini-How-To for the basic configuration I described above.

The MS KB Article to enable IP forwarding in order to open up the VPN to allow the client to use the entire subnet. 

Tags: OpenVPN

Note: The rant contained in this post is probably only relevant for a short period of time. I’m sure that Dell and VMware will make this better. At least I hope so. And I hope they don’t make it better ONLY for brand new servers. I hope they fix it for servers that are six months old too.

My Task: Get monitoring/management alerts for hardware status such as RAID volumes, physical disks, fans, power supplies, etc, for a Dell PowerEdge 2950 III server, purchased less than 6 months ago.

ESXi 3.5 update 4 has the Dell CIM agents and things built into it, I am told. I am also told that OpenManage 6.0.3 can talk to these agents directly. However, nobody can tell me exactly how this works. Can you install it on a VM and then point it to the ESXi management IP? Do you still need Dell IT Assistant, or does it still rely on configuring SNMP traps (a task I enjoy about as much as whacking myself in the shin with a rubber mallet). Nobody at Dell seems to know. To be fair, u4 was only released yesterday. Nobody at Dell seems to have been trained on this yet. They were even surprised to learn that OM 6.0.3 had been released. Eventually one of them told me that 6.0.3 only works with the brand new Generation11 servers. Lovely.

For “older” servers, it’s even more fun. I did hours of research. I downloaded OpenManage Management Station, which includes IT Assistant. The readme file states clearly that 64-bit Windows 2008 is supported - but when the installer runs the prerequisite check, it tells me that “IT Assistant cannot be installed on a system running a Microsoft(R) Windows(R) x64 operating system. What?! There are a ton of other prerequisites too. SQL Express, Java, some portion of Visual Studio (which will trigger a 450MB Windows Update for the entire VS SP1, which will fail and need to be installed manually). Then you need the ESXi Remote Command Line Utility, which in turn requires ActivePerl. You really wanted to install all of that junk on your SBS server, didn’t you?

I gave this one final shot. I actually installed SQL, Java, some Visual Studio thing, SNMP services, the ESXi RCLI, and even ActivePerl. I jumbled all of that crud onto my beautiful, uncluttered, stable server (snapshot first) and started going through the Dell PDF that tells how to enable SNMP on ESXi (msmpa02.pdf, page 10).

I got as far as executing the Perl script, and got this error:
Changing community list to: public…
Failed : fault.RestrictedVersion.summary

OK, that’s it. I am done. Forget it.

So much for the altruistic statement on Dell’s website that says:
“Virtualization is a key path to simplifying IT. Dell and VMware are committed to making virtualization accessible to the mainstream. It shouldn’t be just for the largest datacenters. It shouldn’t be complicated. It shouldn’t require an army of consultants.”

That’s very nice politics but I don’t see it happening. When VMware and Dell pull this together well enough that I don’t need 538MB of junk from either different vendors, a bunch of command line scripting, SNMP configuration, and lots of figuring things out, then I will be interested in working out how to get alerts when hardware events happen.

The VI client has all of the health status indicators right there. It would probably be 50 lines of code to have ESXi send SMTP notifications when any of those dots goes yellow or red. VMware needs to write that into ESXi – but they won’t, because they want people to buy the full Virtual Infrastructure for $3000.

Tags: Dell OpenManage, ESXi, Monitoring

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

If you had a utility that made use of the /console switch in remote Desktop Connection, and this utility made things a lot easier for you, then maybe you were kind of irritated when MS decided to change the switch to /admin in the latest version of Remote Desktop Connection.

Of course, this is a transitory problem. Eventually, since they aren’t allowing access to Session 0 in Windows 2008, this will cease to be relevant. That will happen when there aren’t any servers out there still running Windows 2003.

Of course, since there are in fact still servers out there running Windows NT 4.0, you might not want to hold your breath about that, and you might want to use the /console switch in the meantime.

Well, I think I found a way to do that.

I fired up a brand new Windows XP SP2 OS, and before upgrading to SP3, I grabbed a copy of these files:
c:\windows\help\mstsc.chm
c:\windows\system32\mstsc.exe
c:\windows\system32\mstscax.dll
These files can also be found in the $NtServicePackUninstall$ folder.

After installing SP3, I renamed these files, and replaced them with the older versions.

Maybe there is a good reason to keep the new ones. Maybe I am missing some awesomeness that I have yet to recognize in the new version of Remote Desktop Connection, and this is a mistake. That’s a risk I am willing to take.

It is also possible that these files will keep getting replaced every time a round of MS Updates comes out, and this will become too much trouble to keep up. For now, it seems to be working, and once again of my favorite tools has one of its most useful features back.

Tags: /console switch, Remote Desktop Connection