Archive for the ‘Networking’ Category

Prerequisites for this upgrade/migration are that the SBS 2003 server must be at SP2, with Exchange 2003 also at SP2. In addition to this both your domain functional level AND forest functional level must be running at 2003 native (This is the highest available on SBS 2003 SP2). Finally, your Exchange organisation must be running in 2003 native mode.

The first steps involved are upgrading the Active Directory schemas, for this you’ll need to put the Windows 2008 R2 DVD into your 2003 SBS server, open a command prompt and run the following commands:

X:\support\adprep\adprep32.exe /forestprep
X:\support\adprep\adprep32.exe /domainprep
X:\support\adprep\adprep32.exe /domainprep /gpprep

Obviously replacing X with your DVD drive, or it could be a network share etc. In previous versions of Windows Server, you would have to use the correct media to match the architecture of your SBS 2003 server, as of Windows server 2008 R2, x86 is no longer supported, hence the adprep32.exe instead of adprep.exe!

At this point you can fire up the new (x64!) hardware that you’re going to use to run Exchange 2010. Install Windows 2008 R2 onto here, give it a static IP, a name, all the patches and updates it wants, service packs, also do a full IIS install from the server manager page, it’s probably also a good idea enabling remote desktop at this stage! We’ll need a small selection of remote server amdin tools for during the Exchange installation, so run the following command to install them:

ServerCmd -i RSAT-ADDS

We can now go ahead and join the new server onto the domain, once you’ve done this reboot as requested. When the system has come back up, put in the Exchnage 2010 DVD, and fire up a command prompt and run the following command:

X:\Setup.com /PrepareAd

These will prepare Active Directory and your Exchange organisation for the new Exchange server while still allowing for compatibility with Exchange 2003 SP2. If you get any errors here, it might be worth double checking the functional level of your exchange organisation, as mentioned in the prerequisites. Hopefully you haven’t encountered any errors, so can run the main Exchange 2010 setup from the DVD. Select the languages you want to install, and then proceed through the setup. You’ll need to select the current Exchange 2003 server in the mail flow configuration screen, so that mail can route between both Exchange servers during the migration.

The Exchange 2010 setup will then perform some readiness checks, if any of these fail, do what needs to be done, then click retry! Exchange 2010 should then install the relevant roles onto the system.
Once the Exchange setup has completed, it’s probably a good idea to install any updates. While they are installing, have a look on the SBS server, you should now see two administrative groups in the Exchange system manager.

Add a SMTP send connector as required on the 2010 server (Org config > Hub transport > Connector > SMTP), also allow inbound anonymous SMTP connections (Org config > Hub transport > Default > Permissions).

I’d also advise moving the location of the mailbox database and public store databases, as they are on the system drive by default, it’s a good idea to keep logs and databases on separate RAID volumes. You can move them under Org config > mailbox > databases.

I choose to move public folders first, as this can take a long time, so we keep user mailboxes where they are for now. To move the public folders, use the Exchange management on the 2003 server, right click the public folder store, and select move all replicas – take note of the message and what it says – it will take a long time, and it is only complete once the instance store folder is empty as it says. You can check things are moving by using message tracking in the Exchange 2010 powershell. One you are sure this has completed, you can delete the old public folder store in exchange 2003, select the new public folder store when you are asked where to move the existing bits and bobs to, once this has been done, it’s advisable to unmount then remount the public folders database using the exchange 2010 manager.

The final set with regard to the public folders, is to create a new container on the 2010 server, by right clicking on the 2010 exchange group, then selecting new public folder container, once this has been created, simply drag the public folders from the 2003 group into the 2010 folders group.

Now onto moving user mailboxes, easiest way is by using the Exchange 2010 management console, under server > recipient config > mailboxes > new local move. Follow the wizard to move everything over.
Before we are ready to decommission the old 2003 server, we just need to move the offline address book over, this is under Org config > mailbox > offline address book, right click it, select move and use the wizard. We then need to assign an offline address book to our mailbox database – right click it under Org config > mailbox > properties > client, and pick the offline folder.

We can now delete the 2003 mailbox store, say ok to the warnings, then delete both routing group connectors between the two servers. Using 2003 manager, change the recipient policies, so they only have email addresses – not mailbox manager. Finally we need to delete recipient update services for the domain, then the enterprise – although the latter will need doing via ADSIEdit.msc!
Finally, using add remove programs, change the SBS installation so that it doesn’t include Exchange.

At this point, our 2003 Exchange server is decommissioned, and we’ve now running on the new 2010 version.

When trying to access a windows server via a DNS alias (e.g. using \\fileserver.company.co.uk that is an alias of \\SERVER12), you will probably get a ‘duplicate name exists on the network’ error. This is because the default behaviour of windows only permits using the proper name of the server (SERVER12 in this case, or a bound IP address). This applies to both CNAMEs and A records in DNS.

You might have aliases set up so that if you ever move a service onto a different server, all you have to do is update the alias.

To enable a windows server to respond to aliases like this, you’ll need to edit the registry. Navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

Then add a new DWORD value, called DisableStrictNameChecking and the the value to 1.

Once this is done, you’ll need to restart the server service, after that you should be able to access the server using the alias name!

For a long time I have been trying to find a solution for rolling out a standard wireless profile so that anyone with a Laptop can visit any remote site with a WIFI connection and just connect without searching for a new network and without entering a new password everytime.

I stumbled upon the solution the other day whilst trying to solve another problem. If you take a look at this webpage that is on the Symantec Juice website (click here). If you use the file attached at the bottom of the post called WLAN.exe, it will allow you to export an existing WLAN profile saved on your laptop into an XML file. What you can do then do is create a script to import the XML file using the WLAN.exe utility to create the WLAN profile. What I have done is use Altiris to run this script on all client computers, as this process made it very simple to deploy. The script can be found at the end of this blog.

Firstly, you will need to have the WLAN profile already created on your computer. In my case I set-up a test WLAN environment with an SSID of “Test-Wireless” along with a WPA key of “@test-w1rele55!”. Once this was saved, I could use the utility to export the Test-Wireless profile to the XML file (you only need to do this once as long as the settings do not change!). But first, you need to do the following:

You need to find the GUID of your WIFI card, which you can find out by using the WLAN.exe tool and issuing the following command:

WLAN.exe ei
There are 1 interfaces in the system.
Interface 0:
GUID: 4ccd4bf2-4876-4993-a3de-3ed1cdf54eeb
Intel(R) PRO/Wireless 3945ABG Network Connection - Packet Scheduler Mini port
State: “connected”
Command “ei” completed successfully.

You then need to export the WLAN profile for your chosen WLAN network (in this case “Test-Wireless). In the below example you need to pass WLAN.exe your GUID of your WIFI card:

WLAN.exe gp 4CCD4BF2-4876-4993-A3DE-3ED1CDF54EEB Test-Wireless

This then produces the following ouput in the command prompt window:

< ?xml version="1.0"?>
<wlanprofile xmlns=”http://www.microsoft.com/networking/WLAN/profile/v1″>
<name>Test-Wireless</name>
<ssidconfig>
<ssid>
<hex>4A4E422D576972656C657373</hex>
<name>Test-Wireless</name>
</ssid>
</ssidconfig>
<connectiontype>ESS</connectiontype>
<msm>
<security>
<authencryption>
<authentication>WPA2PSK</authentication>
<encryption>TKIP</encryption>
<useonex>false</useonex>
</authencryption>
<sharedkey>
<keytype>networkKey</keytype>
<protected>false</protected>
<keymaterial>12754EB0C3B25D3F9268E1C49C1E09E5FAD4F9930A67CEB8E3BC944A68047D67</keymaterial>
</sharedkey>
</security>
</msm>
</wlanprofile>

If you copy and paste the text into Notepad, you will be able to save it as an XML file (call it testwireless.xml).

Now that you have captured your WLAN profile, you are ready to think about deploying the profile. To deploy, test it on your computer. Delete the Test-Wireless network in your WLAN network list, and then issue the following command:

WLAN.exe sp 4CCD4BF2-4876-4993-A3DE-3ED1CDF54EEB testwireless.xml

If you check your list of Wireless Networks, you should find that Test-Wireless should be there along with the WPA key already entered!

That is the manual way of doing it, if you need to automate this amongst a different number of computers you face a problem in that for each computer that requires the WLAN profile, the WIFI GUID will be different on each machine! This did cause me some problems, but after messing with PowerShell for a few hours I managed to create a very simple script that will find the GUID of the machine that you want to deploy the profile to and then pass the GUID to the command line. Here is the PowerShell script to automate this:

$path = "HKLM:\Software\Microsoft\WZCSVC\Parameters\Interfaces\"
$guid = Get-ChildItem -name $path
$guid = $guid.TrimStart(”{”)
$guid = $guid.TrimEnd(”}”)
.\WLAN.exe sp $guid testwireless.xml

And there you have an automated way of deploying a WLAN profile. This will prove to be a great time saver for our IT department & I hope someone will find this useful!

During migration to our new one of our new firewalls, I became aware that our outbound mail was not getting out and the queue was just growing. After a bit of digging around I found that our internal mail server could establish a SMTP connection to the server it was trying to send to, the message just wasn’t going down the connection.

I telnet’ed to the SMTP server that we were trying to deliver to, to try and manually send a message by issuing SMTP commands, the conversation went something like the following:

RECV>  220 ****2************************************
SEND> HELO mail. squiggle.org
RECV> 500 5.5.1 Command unrecognized: “XXXX”

Every command that I issued resulted in not being recognised, but each letter substituted as XX’s. After a bit more investigation (netcat listning on port 25 to see what was really being sent), it became apparent that something was altering the SMTP commands, and also the server header on the initial 220 by the looks of it.

After looking into what could be making these alterations, I found out that the likly culprit was our newly configured Cisco PIX firewall… Cisco fixup can run on a firewall and inspect the data in a SMTP session, to try and secure it more, by restricting it to a certain commandset, ours just looked to be restricting the whole lot! Disabling the fixup for SMTP with the following command fixed the issue:

> no fixup protocol smtp 25 

As soon as this rule was added, mail started flowing again!

From time to time you’ll come across the problem where a system’s machine account in active directory has either become out of sync (Usually due to multiple systems with the same name) or has just been deleted somehow! Telltale signs of this are errors about domain’s being unavailable, and trust relationships failing whenever the system tries to perform any authentication. In these situations you can usually log in as a local administrator, unjoin/rejoin the domain, then reboot and the problem is sorted.

However, this isn’t so easy if you aren’t in front of the system (which is often the case), although it is possible to do:

First you need to locate the IP address of the system (Names will be unreliable if you’ve got multiple systems with the same name!). The best way to find the IP is probably from looking at DHCP leases on your DHCP server. Once you have the IP address, run regedit.exe on another system, then from the file menu select ‘Connect remote registry’. In the following box, connect to \\<IPaddress>. You should then be able to log on to the system as the local admin user (SYSTEMNAME\Administrator), you should then be able to navigate to:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server

In this key, look for the ‘fDenyTSConnection’ value, and set this to 0. This should enable remote desktop if it isn’t already, you’ll need to reboot in order to enable this:

shutdown -m \\<IPAddress> -r

Once the system has rebooted, you should be able to remote desktop to it, log in as the local admin user, and rejoin as if you were in front of it. Although if it was a case of multiple systems with the same name, don’t forget to give it a unique name!

I should also point out that if it was a deleted computer account, you could always restore the object in AD, but that’s another story…

I was faced with a problem the other day, where a user wanted to use an application from one of our remote offices. This particular application requires internet access in order to authenticate the license. Due to our setup, we do not allow users internet access locally from the office.  I first tried to edit the proxy.pac to allow the application to go direct, which didn’t work. I then realised that a hole had to be made in the firewall in order to allow the application to go directly through the firewall.

So if you want to do this with a Cisco PIX, then it can be done easily via the command line (as an example, I will use the Google Earth app as the external hosts are well documented):

Step 1: Create a new object group:
object-group network GoogleEarth

Step 2: Add a description onto the object group:
description Google Earth Hosts

Step 3: Create a network object for each destination IP that your application needs to go direct:
network-object 64.233.183.190 255.255.255.255
network-object 64.233.183.93 255.255.255.255
network-object 64.233.183.91 255.255.255.255
network-object 64.233.183.136 255.255.255.255
network-object 65.87.18.132 255.255.255.255
network-object 65.87.18.134 255.255.255.255

Step 4: Create an ACL so that the PIX knows what to do when the object is fired:
access-list inside_access_in remark Unrestricted outbound access to Google Earth
access-list inside_access_in permit tcp any object-group GoogleEarth

Step 5: Create pdm’s for each IP Address listed in Step 3, whilst stating what Interface the IP is on:
pdm location 64.233.183.190 255.255.255.255 outside
pdm location 64.233.183.93 255.255.255.255 outside
pdm location 64.233.183.91 255.255.255.255 outside
pdm location 64.233.183.136 255.255.255.255 outside
pdm location 65.87.18.132 255.255.255.255 outside
pdm location 65.87.18.134 255.255.255.255 outside
pdm group GoogleEarth outside

Don’t forget that if you use a proxy.pac, to set the following Google Earth external hosts to go direct:
http://kh.google.com/
http://geo.keyhole.com/
http://auth.keyhole.com/

There isn’t much documentation on configuring the Cisco PIX, so I hope this helps someone!

To keep active directory clean of old computer accounts, I run a script on a monthly schedule that finds computers that haven’t sync’d passwords for their machine accounts in 120 days or so. It also does some other clever stuff like working out which user the system belonged to, and if they have a new system, then emails the output and action is taken appropriatly (I doubt many people want auto-deletions of system accounts!).

Someone pointed out to me that a very old system wasn’t getting picked up by the script, so I had to do some debugging…

Running Microsofts AD LDAP browser (adsiedit.msc) let me find the system in question, and looking at the properties of it there was a value for ‘pwdLastSet’, but it wasn’t in a standard date format. After a bit of research, it turns out that this is in the Integer8 format,  this is a 64-bit / 8 byte number that stores the date/time in 100nanosecond intervals. Great. But when the hell was ‘128509137717192405′ ?!

Easy… You can convert a Integer8 date format by using the ‘w32tm’ command….


Z:\>w32tm /ntte 128509137717192405
148737 10:16:11.7192405 - 25/03/2008 11:16:11 (local time)

So that explains why the system wasn’t appearing in my old systems list, it had sync’d passwords only a couple of months ago.

Sniff sniff

June 10th, 2008 No Comments

I had a problem today with one of our FTP servers… We have a client that has an automated process set up that uploads data to our server, which is then processed by us.

I had to recreate the account used for this, but then realised I didn’t know the original password, and getting the client to find it wouldn’t be an easy option!

After a bit of digging for a packet sniffer, I came accross Smartsniff and was instantly impressed!

In action

It’s one of those tools that you can pick up and start using right away, without having to spend ages installing dependancies or figuring it out, and it’s just a single exe, so very portable. I also really like the fact that it assembles certain TCP communications into a readable conversation (See above) – very easy to recover a saved FTP password that you don’t know!

Get it from nirsoft.net, along with a whole stack of other neat tools!