Skip navigation

Tag Archives: Exchange

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 http://www.microsoft.com/downloads/details.aspx?familyid=429163ec-dcdf-47dc-96da-1c12d67327d5&displaylang=en

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: http://www.debianhelp.co.uk/backuppc.htm

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…

By default, Microsoft exchange uses the username when creating email addresses for users using Recipient Policy.

eg.

username@domainname.com

However, in many cases the standardised email address format is slightly different – for example:

firstname.lastname@domainname.com

This is actually really easy to edit in the Exchange System Manager using a few variables:

%g  = Given Name (First name).
%3g = means first 3 letters of Given Name
%s  = Surname (Last name).
%3s = means first 3 letters of sn.
%d  = displayname.
%m  = Exchange alias.

Once this has been edited, just right click on the Policy and click Update this Policy now.

Thanks go to Simon Butler for this (aka. Sembee on Experts-Exchange or http://www.amset.info).  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…

NOTE:  THIS SOLUTION INVOLVES EDITING THE REGISTRY ON YOUR SBS SERVER – USE AT YOUR OWN RISK!

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
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters]
“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:

NOTE: THIS NEEDS TO BE ON A SINGLE LINE AND EDITED TO SHOW SERVER SETTINGS FOR YOUR SERVER

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftRpcRpcProxy]
“ValidPorts”=”server:100-5000; server:6001-6002; server:6004;server.domain.local:6001-6002; server.domain.local:6004; mail.external.com:6001-6002; mail.external.com: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:

http://support.microsoft.com/kb/911829

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

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:

http://www.dsbl.org/relay-methods

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:

http://legacy.dillfrog.com/tools/base-64_encode/

Very useful 🙂

I was just looking through some old notes on how to set up Windows Mobile Devices for Direct Push

(Calendar, Tasks, Contacts and Email!!!) with a self signed SSL certificate (you can’t just install

the 64bit .cer file as it won’t allow the file type).

Anyway, thought I’d publish the solution here….
Note: this only works on Windows Mobile 5 and above – not WM 2003 🙁
I’ll assume here that people know how to create the SSL certificate (if not theres a good guide

at http://www.petri.co.il/install_windows_server_2003_ca.htm)
Next download the SSLChainsaver tool to the root of your C: drive
http://blogs.msdn.com/windowsmobile/archive/2006/08/11/sslchainsaver.aspx
Follow the instructions on the page to pull a copy of the root and leaf certificates, then

export the ROOT certificate in Base-64 encoded format.
Open the certificate from a command prompt using the line:
C:Type rootcert.cer
Which will output the hash of the certificate, which will look like:
C:>type rootcert.cer
—–BEGIN CERTIFICATE—–
MIIEYzCCA0ugAwIBAgIQG4HnhkoEsahFnmBPR65JWjANBgkqhkiG9w0BAQUFADA9

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

A1UEAxMHYmhzcnYwMjAeFw0wNTEwMDMxNzA3NTRaFw0xMDEwMDMxNzE1MjFaMD0x

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

VQQDEwdiaHNydjAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2GTQ

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

N2RtoT4HcNUHYyDTlLrydD4tCOq21o4cNHRk67UsRGRHjZz/BI1YsdOXl1rakOva

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

COsC4ULQDytkuw9gCifqiCyxnT0k7+zkIgNxF4ncFdbnESLm3Bw2wCBz1G/MtUwY

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

2AiOz+jgGeYKv9jD8wIDAQABo4IBXTCCAVkwEwYJKwYBBAGCNxQCBAYeBABDAEEw

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

5a5dW4PRqcsXEAMtMIHyBgNVHR8EgeowgecwgeSggeGggd6GgatsZGFwOi8vL0NO

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1iaCxEQz1sb2Nh

bD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JM

RGlzdHJpYnV0aW9uUG9pbnSGLmh0dHA6Ly9iaHNydjAyLmJoLmxvY2FsL0NlcnRF

bnJvbGwvYmhzcnYwMi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJKoZIhvcNAQEF

BQADggEBAEGdXuUfA7kvCxLLOI+W3+Nbz7lENOZF59cNVaQJ5HwjIGtLhw2tv2c0

SibjlB68ecuyuD6K4gYLVlhZrLelDKqGYsV3uF+Q4293+t2S+D3cMXW/gPAYeBU2

Ld+P6dm4tjmzcSC/Xpi3mQpw8kQF93rEEkApbP4LOXh/X5LpyZ2iS15RTMMomxvL

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

ILk4wkjERNGgRRl5eOF3QZ/hMWRu1UMb1C6mrcxs4pBW1qyOJQNJB+Y3eHuWCzfw

oZMi16R2/MCkY6xCqvDRj302UKLHUbU=
—–END CERTIFICATE—–
Create a new file in notepad using the following template and call it _setup.xml, then paste the cert above into the section as below.

Then open your root certificate, look at the thumbprint of the certificate and copy that into the characteristic type section (highlighted in red above, without the spaces). My Thumbprint looked like 963688b77d91307e0164661f9550e2a2

Finally, all you need to do is make the .xml file into a cab file for installation into the Windows Mobile Device using the command line makecab (which ships is %systemroot%system32 with windows

Makecab _setup.xml rootcert.cab

Copy this to your Windows Mobile device with Activesync, then run.

You should now have an appropriate certificate to allow you to use Direct Push Email

through Exchange Activesync…..

Hoorah!!