Skip navigation

Category Archives: Active Directory

I’ve seen so many people attempt to restore Exchange and fail using Microsofts built in tools, or come unstuck because they want to restore a single mailbox, that I thought I’d document the free method of backing up Exchange that we use, so that it will hopefully help others.

One of the tools available from Microsoft free is Exmerge.  It allows individual mailboxes to be individually exported to PST files, which can then either be re-imported back into Exchange or simply opened in Outlook.  Exmerge is available from

Extract and save to the Exchsrv/bin directory, and when the appropriate mailboxes have been selected, destinations set save the configuration.  This will create an exmerge.ini file.

This can then be scripted in a batch file and run as a scheduled task.  I create a folder on the local disk of the Exchange server (although this can be done to a mapped drive) for each day I want the backup to run.

My exmon.bat file reads:

D:\exchsrvrbinexmerge.exe -F C:\scriptsexmonexmerge.ini -B

Which runs the exmerge.exe, with the options specified in scriptsexmonexmerge.ini and runs the script as a batch job using the -B switch.

To clean the folder prior to running, I have a separate batch file that runs earlier on the same day that runs

del /F /Q /S z:\Exchangeexmon*.*

Subsequently to back up the PST files to a separate server I use the excellent BackupPC running on a Debian server.  Installation instructions for Debian are here:

The BackupPC box is confugured to access the SMB share that the PST’s are stored in, as well as additional file shares on the server.  BackupPC supports incremental backups and backups via a variety of methods (including SSH and rsync, as well as SMB).

It’s also possible to archive off historic backups for off-site using the archive functions within BackupPC.  As a free solution for backing up mailboxes and beiong able to recover easily (with version control) this is very effective…

I’ve just had to migrate a batch of printers to a new AD print server. Fortunately this process was made somewhat painless by the Microsoft Print Migration tool available here:

This error occurs when trying to view Public Folders in the Exchange System manager when he SSL certificate name differs between the FQDN and the local server name.  The Exchange System Manager will not allow you to view the public folders as it believes the folder name to be incorrect.

This can be resolved using a front-end, back-end scenario, but what if you are stuck with a single Exchange server (ie. SBS) in your environment?

On following a few blogs and sites, the solution seems to be to remove SSL requirement for that particular folder in the IIS Manager.  This didn’t work for me though – and I found a lot of people out there with unresoved issues on Experts Exchange etc.

The end solution was to use the ADSIEdit utility to manually stop the Exchange System Manager from using SSL.

The steps are as follows:

1) Install the ADSIEdit Utility (one of the Windows Server 2003 Support tools) from your SBS2003 CD (CD2) using suptools.msi

2) Run a Microsoft Management console (Start->Run->MMC)

3) Open the ADSIedit.msc (browse to the Support Tools folder)

4) Browse through to

Configuration > Services >  Microsoft Exchange > Domain Name > Administrative Groups >     First Administrative Group > Servers > Servername > Protocols > HTTP > 1 > Exadmin

5) Right click msExchSecureBindings, and click Properties

6) Highlight :443: and click Remove

7) Click OK

8) Restart the Exchange System Attendant and the IIS Admin service

Exchange system manager will now no longer try to use SSL when connecting to the service.

Thanks go to Simon Butler for this (aka. Sembee on Experts-Exchange or  His resources on this helped me iron out the problems and get this working beautifully!

I’d struggled getting RPC/HTTPS working for ages using a self -signed certificate, and while it’s still recommended using a purchased certificate, I needed to get a particular user working extremely quickly – within about 4 hours.  Waiting for appropriate DNS to propogate to get the cert approved wasn’t an option so the existing self signed cert I used for OWA was the only option…


First things first, the certificate needed to be installed in the Root Certification Authorities store on the client machine.  Note that adding the cert to the default store WILL NOT work.

Then create split DNS by adding the corresponding external DNS zone to your internal DNS server, and a host record for the SBS server.  Remember, if your external web site is hosted externally you need to ensure that there is an A record that points to the web servers IP address.

Next, a couple of Registry keys needed to be added (I would have never have sussed this if it wasn’t for the resources on Amset!). A reg key needs to be created on the SBS server as follows:

Windows Registry Editor Version 5.00
“NSPI Interface protocol sequences”=hex(7):6e,00,63,00,61,00,63,00,6e,00,5f,00, 68,00,74,00,74,00,70,00,3a,00,36,00,30,00,30,00,34,00,00,00,00,00

Copy and paste the above into notepad and save with a .reg extension, then run.  This will create a key that looks like:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters Type REG_MULTI_SZ Name: NSPI Interface protocol sequences Value: ncacn_http:6004

Next on the Exchange server (this will be the same machine if using SBS) a different registry key needs to be created:


Windows Registry Editor Version 5.00
“ValidPorts”=”server:100-5000; server:6001-6002; server:6004;server.domain.local:6001-6002; server.domain.local:6004;;;”

Save as a .reg file and run.

Then simply configure Outlook to use RPC over HTTPS and specify the FQDN of the server.  You can test the connection by holding CTRL and right-clicking the Outlook icon, then looking at the Connection Status in the taskbar.  If it is trying to resolve the external FQDN of the server then Outlook is configured correctly. Then just ensure that port 443 on your firewall is forwarded to the SBS server….

….sorted 🙂

A couple of people have asked me about what causes the accursed “red cross” when editing/composing an email in OWA in Vista and newer versions of internet explorer and how to resolve it.

It turns out Microsoft have discontinued support for the ActiveX control that is used in the OWA Compose/Edit window, but have released a hotfix here:

Fortunately it doesn’t require a restart of the Exchange server….

Just been trying to find out the CD key for one of the Windows installs in the office and stumbled across this:

Previously I knew how to test for traditional Open Relays on mail servers – but was looking for some more extensive testing and stumbled across this site:

Among the list is methods of testing against double bounce and webmail relaying….

In addition to this the base-64 encoding and decoding tool can be used to test SMTP Auth on servers:

Very useful 🙂

After struggling to fully join a linux box to the AD domain at work, I’ve now successfully managed it.
This was done in Fedora Core 8, but theres no reason why this shouldn’t work regardless of distro.
Going to give it a go on Ubuntu next!!  (Note that the Active Directory domain in this is example is RC.local and the AD/DNS/Kerberos server is RCSRV01 – replace these entries with your own details…)
Here’s a checklist to follow:

1 – Ensure that the AD domain is correctly configured (DNS,DHCP, etc)

2 – Add the AD domain controller as the first DNS server on the linux box
(and check using /etc/resolv.conf)

3 – Ensure the kerberos and samba packages are installed on the linux box

4 – Set the hostname on your linux box in /etc/sysconfig/network

5 – Ensure you have the correct hostname (using your FQDN) in/etc/hosts. Mine looks like:

# Do not remove the following line, or various programs
# that require network functionality will fail. RCFedora rcfedora.rc.local localhost
::1 localhost6.localdomain6 localhost6

6 – Ensure your linux box is set to use the Windows Domain controller as an NTP server
and that your time zone is correct (this caught me out – the time zone was incorrectly set
and it wouldn’t allow me to join the domain!)

7 – Edit /etc/krb.conf to include the following on the FIRST 2 LINES!!

RC.LOCAL rcsrv01.rc.local:88
RC.LOCAL rcsrv01.rc.local:749 admin server

8 – Next I added the file /etc/krb.realms, and added the following line

.rc.local RC.LOCAL

9 – In /etc/krb5.conf, check that the following options are there and correct:


default_realm = RC .LOCAL
dns_lookup_realm = true
dns_lookup_kdc = true

kdc = rcsrv01.rc.local:88
admin_server = rcsrv01.rc.local:749
kpasswd_server = rcsrv01.rc.local:464
kpasswd_protocol = SET_CHANGE
*.addomain.local = RC.LOCAL
.addomain.local = RC.LOCAL

10 – Next check /etc/nsswitch.conf for the following entries:

passwd: compat winbind
group: compat winbind
hosts: files dns winbind

11 – Check /etc/pam.d/system-auth for the following in the session section

session required skel=/etc/skel umask=0022

12 – Under the global settings in the /etc/samba/smb.conf you should have the following

unix charset = LOCALE
workgroup = RC
netbios name = RCFEDORA
password server = RCSRV01
realm = RC.LOCAL
server string = Fedora8
security = ads
allow trusted domains = No
idmap backend = idmap_rid:RC=16777216-33554431
idmap uid = 16777216-33554431
idmap gid = 16777216-33554431
log level = 1
syslog = 0
log file =var/log/samba/%m
max log size = 50
template shell = /bin/bash
template homedir = /home/%U
winbind use default domain = yes
winbind offline logon = true
winbind enum users = Yes
winbind enum groups = Yes
winbind nested groups = Yes
printcap name = CUPS printing = cups

and under HOMES you should have

comment = Home Directories
browseable = no
writable = yes
; valid users = %D%U
; valid users = MYDOMAIN%S

13 – Finally stop the Winbind and Samba services, and run the following commands:

rm -f /etc/samba/*tdb
rm -f /var/cache/samba/*tdb
rm -f /var/cache/samba/*dat
net ads join -U Administrator

then start the winbind and samba services again and reboot!

You should then be able to log on with domain credentials!