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.

A few days ago a colleague asked me if I knew of a way of recovering files without purchasing a dedicated file recovery solution.  By all accounts he had some important reports which had ‘gone missing’, though of course he swore that he had not deleted them himself.  My first question was simply why not restore them from a backup?  I can’t stress enough to people the importance of backups, not only for important business documents but also for personal files such as photos and memories which you simply cannot replace.  He looked rather abashed when he told me that he had not been following his backup schedule and the only copy of the reports was on his machine; or at least they were.

Well fortunately for him there is a way, and you won’t have to reach for your credit card either.  Windows (see note below) has a little-known feature built in called “Previous Versions” which automatically stores copies of files historically, an integrated and invisible backup if you will; the files are captured using the shadow copy component of Windows.

Note: Shadow copy or using its correct term Volume Snapshot Service, is a component of Windows included with the following, Windows XP Service Pack 2, Windows Server 2003, Windows Vista (although only in Business, Enterprise and Ultimate editions), Windows Server 2008 and Windows 7 (although again, only in Professional and Ultimate editions).  Although not included, it was also available for Windows 2000 and Windows XP.  If you have one of the home user versions, there is also a way of recovering files but using a slightly different method.

So, to be able to restore a file or even an older version of a file you simply need to know which folder the file was in and then follow this guide (I am using ‘My Documents’ as an example):

• Go to your My Documents folder (in my case, Start>$USER>My Documents), then right click an open area on the screen and click Properties.  Don’t navigate via one of the Libraries as this will confuse matters
• The Document Properties dialogue box will appear, click the Previous Versions tab and then double click the most recent date where you know or suspect the file to have been before it was deleted (Note: depending on the specification of your machine and the amount of data stored, this may take a little while, but don’t panic)
• A new Explorer window will now open which will show all of the files as they were in the directory at that time, you should now see the deleted files.  To recover them, simply cut and paste them back into your current My Documents folder and go make yourself a congratulatory mug of coffee, safe in the knowledge you have just saved yourself money by not having to purchase dedicated file recovery software

That’s all there is to it, but please, don’t rely on this method as an alternative to a proper and up-to-date backup.

Let me know if you find this useful by leaving a comment below, and don’t forget to sign-up for further guides using the option on the right.  This way you’ll get the latest guides delivered directly to your inbox.

For those who are interested, the very latest incarnation (albeit in Beta) of Microsoft’s Internet Explorer is now available to download from here.

Review and my thoughts to follow shortly…

It’s been over a year now since Windows 7 RTM came to market, a year which unusually for a newly released Microsoft OS has been in the main, trouble free.  The transition for many business users from Windows XP to Windows 7 has been easier than with previous incarnations, certainly surprisingly simple considering there is a decade separating the two operating systems which let’s face it in the ever changing world of IT, is a huge gap.

Overall Windows 7 has been a massive boost for Microsoft generally with the latest figures telling us that more than 150 million licences have already been either installed or at least sold.  So what does this tell us (apart from the size of Microsoft’s bank balance)?  Well, importantly it means that Windows 7 has now effectively overtaken the installed user base of Windows Vista during its first year of sale which let’s face it is huge for Microsoft although for us; not at all surprising given that Vista is far from perfect (or even good actually).

I was an early adopter of Windows 7 and moved my primary machine to Windows 7 Ultimate prior to the official release (I was fortunate enough to be given an official copy by Microsoft prior to the public release date) and was genuinely surprised by the ease of installation compared to prior versions; things like driver installation and compatibility checks are now fully managed by the system.  Owing to Vista being – well – actually quite rubbish, I didn’t transition via Vista and came from using Windows XP on my machines.   Windows 7 is definitely the most stable and robust all round operating system I have used to date for my day to day use, both at home and work.

It’s not all great though, on my T61p battery life is not as good as it used to be and there are a few other areas which have been made unduly complicated compared to Windows XP.  But of course Windows 7 is designed appeal to all, including consumers who demand the fluid, GUI improvements and work arounds which I would historically have done manually via the command line; that’s not to say that this can’t still be done, in fact with PowerShell this is even more powerful than ever.  Let’s not forget that we are still in the infancy of the OS though, with SP1 under development and due to be released soon I am sure some of these annoyances will be addressed making the OS even better.

Of course in the meantime, now manufacturers have more experience of Windows 7 too, updating the BIOS to the latest version will undoubtedly help with any hardware issues such as the increased battery drain, and updating drivers will iron out any system glitches, although they are few and far between.

For sure though, Windows 7 is Microsoft’s most polished operating system to date (although I do still remember Windows 2000 fondly; it just worked!) and it’s safe to assume there will have been some questions raised in the Microsoft hierarchy as to why Vista wasn’t anywhere near as successful.  I’m sure some eye brows were raised.

I look forward to testing Windows 8 at an early stage – I believe the public release date is tentatively set sometime during 2012 – when it becomes available on TechNet, it is most likely to follow in the ilk of Windows 7 and will be Microsoft’s most ambitious project to date, really making full use of cloud and mobile computing whilst fighting off the ever nearer threat from Apple, Linux and most recently Google.

Microsoft finally seems to be heading in the right direction again.

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.