Squiggle dot org

After migrating to Exchange 2010, a small number of users couldn’t get thier iPhones to sync with Exchange, depite managing to verify the account in the iPhone setup. The thing ther users had in common, was that there were created as Administrators by an old SBS2003 system.

When trying to view the inbox from the iPhone, the following appeared in the application log on the exchnage mailbox server…

Exchange ActiveSync doesn’t have sufficient permissions to create the “CN=Freg Smith,OU=Users,OU=XXXXGroup,DC=XXXX,DC=local” container under Active Directory user “Active Directory operation failed on XXXXXXXXXX. This error is not retriable. Additional information: Access is denied.
Active directory response: 00000005: SecErr: DSID-03151E04, problem 4003 (INSUFF_ACCESS_RIGHTS)

This problem is Exchange not having access rights to the user object in active directory, as the SBS account creation tool disabled this for Admin users. To fix the issue, goto the propeties of the user in question in Active Directory Users & Computers, navigate to the security tab, then advanced button, and tick the inherit permissions box. This will allow the required permissions to apply to the user, and mail should start syncing!

Super quick way to move DHCP onto a new server…

On the old server:
netsh dhcp server export \\server\share\dhcpConfig.dat all
net stop “dhcp server”
sc config dhcpserver start=disabled

On the new server:
Install DHCP role
netsh dhcp server import \\server\share\dhcpConfig.dat all
net stop “dhcp server”
net start “dhcp server”

Goto DHCP management tool on the new server and double check the new server is authorised, right click and authorise if it isn’t! Also, don’t forget to properly uninstall the old DHCP server service using add remove windows components, so that it cleans up active directory and it doesn’t remain as an authorised server when the box is fully decomissioned!

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. Read the rest of this entry »

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!

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.

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!

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!