Mike Southby

I’ve had a number of support queries at work recently relating to NDRs being generated when a user sends meeting invites in Outlook reporting that a mailbox does not exist.  Confusingly, the NDRs relate to an account which not only was not invited to the meeting but also no longer exists within the organisation; an AD search for the mailbox yields no results.  It turns out the reason for this is due to one of the invitees having a delegate whose mailbox has been deleted.  If you have come across this issue before, you’ll know how tricky this can be to resolve.

In order to fully understand why this is happening, it’s important to know what happens behind the scenes when a user gives delegate access to their mailbox, not only will this help you to understand why this problem occurs, but it will also help to understand what actions need to be taken to resolve the problem.

Let’s assume you have an existing mailbox for user A who wishes to make user B a delegate.  When the delegation is made the following takes place:

• The appropriate sharing permissions are placed on the relevant folder in user A’s mailbox, these of course will vary depending on which permissions were set using the delegation tool.
• If the checkbox for forwarding meeting requests is set, a special hidden forwarding rule is created in user A’s mailbox.  As this is a hidden rule, you will not see the rule listed in Outlook.
• User B is added to user A’s publicDelegates attribute (or more commonly known as the send-on-behalf-of field), and user A is added to the publicDelegatesBL attribute of user B; this does not always happen depending on a number of circumstances, for example more recent versions of Outlook or when the person trying to set the delegation is not actually the owner of mailbox A.

So far so good, but let’s assume now that some time has passed and for whatever reason user B leaves your organisation and as such, their mailbox is deleted from within AD.  Further, the System Administrator performing this action would have no idea of user configured delegations and AD itself would not intuitively make them aware of any which is where the fun begins.

Once the mailbox for user B is deleted their publicDelegatesBL entry in AD gets cleared out so there is no easy way to work out who they were actually a delegate for; we can now think of them as an orphaned delegate. Even more problematic, the hidden forwarding rule in mailbox A does not get updated; as with security group membership and other AD functions, you’d have hoped this would take place automatically but as this is a client side feature, unfortunately not.

Assuming that you can narrow down whose mailbox has the orphaned delegation, you can manually fix this issue by the using the MFCMAPI tool to delete the hidden forwarding rule but even this is not without issues as unfortunately if there are other delegates to that mailbox, the forwarding for them would break as well.  So all of those delegates would need to be manually removed and subsequently re-added which would involve logging in manually to the mailboxes in question.  This may be a simple task but as in the situation I was faced with, not so.

As you can see, the reality is that you may not be able to actually resolve this issue.  In one of the situations I was faced with the originating user who received all of the NDRs (there were actually over 30 of them) had sent the meeting invite to a distribution list which itself, contained a number of other distribution lists.  Using the MFCMAPI tool I would have had to of manually logged into somewhere in the region of 500 mailboxes to identify who had the orphaned delegates and then subsequently, had to recreate the delegate rules for the users who I ran the tool on.  Needless to say on balance this was not an option.  The MFCMAPI tool is an option in instances where a single user receives NDRs sending to another user, or small group of users but not when large distribution lists are involved.

So just how do you stop the NDRs?

The reality is that you can’t, however you can create an Outlook rule for the sender to prevent them receiving the NDRs by automatically forwarding the NDR messages (the generated NDR error for this issue is 5.1.1 so by setting this rule you would not stop other NDRs being delivered) directly to their deleted items or even permanently deleting the message at source.

I hope someone will find this useful.  Enjoy.

If you are using your iPhone with Exchange 2007 you’ll notice that Exchange now forces a remote policy which requires you to have a passcode on your device (of course this also applies to other mobile devices and not just the iPhone).  I’m sure for some this is not an issue but for those users who do not need this security feature enabled and/or simply do not want to have to enter a passcode every time, there is of course a way to disable the feature.

Firstly, you’ll need to have administrative rights to the Exchange 2007 server, so if you do and you’re able to either access the box locally or remotely via RDP, read on.

Assuming you are now sat looking at the desktop on your server, do the following (I have based this guide on a standard installation of Small Business Server 2008, but of course still applies to a stand-alone build of Exchange 2007, just follow the same steps):

• Click through Start>All Programs>Microsoft Exchange Server 2007>Exchange Management Console
• You’ll be greeted with a Windows needs your permission to continue dialogue box, select Continue
• Once in the console, expand Organization Configuration and highlight Client Access
• There should only be one policy active, which is the Windows SBS Mobile Mailbox Policy <servername>, right click this and select Properties
• Click on the Password tab
• Next uncheck the Require password checkbox and hit Apply then OK
• You can now close all of the open windows

You should now find that the forced passcode is no longer required.

If you found this guide useful, please leave a comment below.  Remember you can also subscribe to any future posts via email by clicking here.

iPhone

Here’s a brief walk through for configuring your iPhone (or iPod Touch) to work with true push-services on a Microsoft Exchange 2007 server.  Thanks to my good friend Steve for lending me his iPhone to have a play with and write this article.

Caveat: This method worked fine for me, but as always you follow this guide at your own risk.  I will not be held responsible for any problems along the way.  Please *do* backup both the Exchange server and your iPhone before making any changes.

What you’ll need:

• IIS (I have used v6, but the basics are essentially the  same for previous versions)
• Exchange 2007 with installed Service Pack 1
• iPhone running 2.1 or greater software

Step 1: Installing RPC over HTTPS

1. On the Windows server that is running Exchange, go to the control panel and then Add or Remove Programs.
2. Click the Add or Remove Windows Components tab, click Networking Services and then click Details.
3. Click to select the RPC over HTTP Proxy check box and then OK followed by Next.  You’ll need to have your Windows server installation disc ready at this point, or the i386 folder if you have made a local copy as some additional files will be needed to install this component.
4. When the Windows Component Wizard has completed installing, click Finish.

Step 2: Configuring RPC with IIS

1. Click Start, go to Administrative Tools, and then click Internet Information Services (IIS) Manager.
2. Expand $servername, expand Web Sites, expand Default Web Site, right click Rpc and then click Properties. (You’ll also notice that Windows Server 2003 Service Pack 1 added a new virtual directory called RpcWithCert.  This virtual directory points to the same location as the Rpc virtual directory.  You do *not* have to modify this)
3. Click the Directory Security tab, and then click Edit under Authentication and Access Control.
4. Click to clear the Enable Anonymous Access check box, we do not want this.
5. Click to select the Basic Authentication (Password is sent in clear text) check box.
6. Now, you should receive the following message: The authentication option you have selected results in passwords being transmitted over the network without data encryption.  Someone attempting to compromise your system security could use a protocol analyser to examine user passwords during authentication process.  For more detail on user authentication, consult the online help.  This warning does not apply to HTTPS(or SSL) connections.  Are you sure you want to continue?
7. Click Yes.
8. If you have not done so already, now would be a good time to enter your domain name into the Default Domain box (you can browse to the domain name by pressing Enter).
9. Click OK.
10. Finally, click Apply and then OK to finish.

Step 3: Configure RPC SSL in IIS

The RPC virtual directory has now been configured to use basic authentication in the above steps.  We are now going to configure SSL.  To configure SSL on the RPC virtual directory you have to obtain and publish a certificate or use the self sign method.  I have used the self sign method in this walk through.  If you only want to access your exchange server without SSL (i.e. using port 80) you can skip the next 3 steps.  This however is *not* recommended.

1. In Internet Information Services (IIS) Manager expand Web Sites.  Expand Default Web Site.  Right click Rpc and then right click.  Click Properties.
2. Click the Directory Security tab and then Edit under Secure Communications.
3. Click the Require Secure Channel (SSL) check box and also the Require 128-bit Encryption check box.
4. Click OK, click Apply and then click OK.

Step 4: Self Sign an SSL certificate for IIS

Next we need to provide a self signed certificate (or a commercially available signed one, iPhone works with both) .  You’ll need a free tool provided by Microsoft SelfSSL which comes with IS 6.0 Resource Kit Tools.  You can download it from http://www.microsoft.com/downloads/details.aspx?FamilyID=56fc92ee-a71a-4c73-b628-ade629c89499&displaylang=en.  Once you have downloaded and installed this, make sure you click Complete Installation.

1. Click Start > All Programs > IIS Resources > SelfSSL > SelfSSL to run the SelfSSL utility.  When you do this, you should have a command prompt window appear with help instructions.
2. Type selfssl.exe and press Enter.  The utility will use the default settings to install the SSL certificate which are:
   /N:CN=<YOUR COMPUTER NAME> (common name of the certificate)
   /K:1024 (key length of certificate)
   /V:7 (validity of the certificate in days)
   /S:1 (ID of the site to which the certificate needs to be installed i.e. Default Web Site)
   /P:443 (SSL port)
3. Press Enter, then type y and press Enter again to confirm the installation.

Step 5: Port Parameters in the Registry

You can manually edit the registry but it is easier and safer to use a utility to do this.  I’d recommend a tool called RPCNoFrontEnd which does all of the changes in only a few mouse clicks, available from http://www.mikesouthby.co.uk/wp-content/uploads/2009/10/rpcnofrontend.zip.

1. Run the tool, all you need to do is input the servers name and click Set registry entries now.

Step 6: Configure Exchange 2007 SP1 to use RPC over HTTPS

1. Click Start, click through Microsoft Exchange and click System Manager.
2. Expand Your Organisation; expand Administrative Groups > First Administrative Group > Servers.
3. Right click on your server name and select Properties.
4. On the General tab, verify that you have SP1 installed.  Also, verify that a tab called RPC-HTTP is also present.
5. On the RPC-HTTP tab, click on RPC-HTTP Back-End Server.  At this point you may get an error, if you do just acknowledge it.
6. Keep clicking OK to exit.

Now, everything is set up as far as the server is concerned.  It’d be a good idea to reboot at this stage.

Step 7: Firewall ports for RPC over HTTPS

On your router, you’ll need to open the following ports:
No-SSL setup: TCP port 80
SSL setup: TCP port 443
if you are also running NAT on your router, you also need to port forward these ports to your server running Exchange/IIS.

Step 8: Configuration of the Exchange Account on iPhone

1. Tap Settings, then Mail, Contacts, Calendars, and then Add Account.  Finally click Microsoft Exchange.
2. Enter your complete email address, domain, username, password and a description for this new account (obviously, this can be anything you like).
3. Your iPhone will now try to locate your Exchange server using Microsoft’s Autodiscovery service.  If the server cannot be located, enter your Exchange server’s complete address in the Server field.  Your iPhone will try and create a secure (SSL) connection to your Exchange server.  If you did not setup SSL, it will try a non-SSL connection.  After successfully making a connection to the Exchange server, you may be prompted to change your device pass code to match any policies that may be enforced on the Exchange server, if so you can choose to do this or change the policy!
4. Choose which type(s) of data you would like to synchronise: Mail, Contacts and Calendars.  By default, only 3 days worth of email will be synchronised, to change this go to Settings, then Mail, Contacts, Calendar and select your Exchange account.  Here, choose how many days worth of email you’d like on your iPhone.

Important note: Once you have configured an Exchange ActiveSync account on your iPhone, all existing contact and calendar information on your iPhone will be overwritten.  Only one Exchange account is permitted.  iTunes will no longer sync contacts or calendar entries to your desktop computer however you can still sync your iPhone wirelessly with MobilMe services.

Please do leave a comment if you find this useful.

The first thing to bear in mind is that Exchange 2007, the latest version of Exchange, will only be supported on 64-bit servers.  Initially this may sound like an odd decision by Microsoft but they claim that almost all new server hardware these days has 64-bit technology anyway which means that new installations will be able to utilise better sizing and scalability options.  If you refer to Microsoft’s documentation, it clearly states that in order to run Exchange 2007 you’ll need x64 architecture with either an Intel Extended Memory 64 Technology (Intel EM64T) processor or an AMD processor that support the AMD64 platform.  The Intel Itanium family IA64 processors are not supported.

You’ll also need a minimum of 1GB RAM although 2GB is recommended and at least 1.2GB of hard disc space, which must be formatted as NTFS.

To check if your processor is compatible, you can use CPU-Z which is available here.