Microsoft Exchange and Remote Desktop Services Specialists

SEMblog

Microsoft Exchange Server and
Blackberry Enterprise Server news, views and fixes.

Why You Shouldn't Use PST Files

This is another post in my series of articles on why you shouldn't use certain features in Exchange, even though they are there - although in this post is about an Outlook feature - PST files.  

The other articles in this series to date are:

Why you shouldn't use logos in signatures (http://blog.sembee.co.uk/archive/2008/04/14/76.aspx)
Why you shouldn't enable the POP3 Server (http://blog.sembee.co.uk/archive/2008/03/03/71.aspx)
Why you shouldn't use the POP3 connector (http://blog.sembee.co.uk/archive/2006/09/25/28.aspx)
Why you shouldn't use a self generated SSL certificate (http://blog.sembee.co.uk/archive/2006/03/05/9.aspx)
Why you shouldn't put Exchange 2003 in to a DMZ (http://blog.sembee.co.uk/archive/2006/02/23/7.aspx)

In this post I am going to outline why you shouldn't use PST files.

Anyone who has worked with Exchange or Outlook for more than 10 minutes will know about PST files. However despite their numerous flaws, they continue to be in widespread use. Where possible you should ban their use, particularly for archiving purposes.

The main arguments against using PST files are:

Data Loss When They Get Too Large

With Outlook 2002 and older, PST files can go to a maximum of 2gb, but in an annoying flaw, the file will allow you to continue to add data past the 2gb limit. You only get problems when you try to open the file again. Microsoft do have a tool that will allow you to open a file that has gone over the limit, but it simply chops off all data over 2gb - therefore resulting in data loss.

With Outlook 2003 and higher a new format of PST file is used (which is not backwards compatible) which allows PST files to go to 20gb. You cannot convert the old version to the new one. If you have create the wrong type then you will need to create it again and move the content across.

PST files are very fragile things, particularly the larger they get. Many people will suggest a new PST file at 1gb or less to protect the data.

Backup of the Files is Awkward

Microsoft do not support accessing PST files over a network. (http://support.microsoft.com/default.aspx?kbid=297019 and
http://blogs.technet.com/askperf/archive/2007/01/21/network-stored-pst-files-don-t-do-it.aspx ).

That basically means they are impossible to backup. You cannot store them locally and backup over a network, and you cannot store them on a network share and access them over the network. Considering how fragile they are this is asking for problems.

Single Point of Failure / Risk of Corruption without Knowing

It is perfectly possible to have a corrupt PST file and not know about it for weeks or months. It is perfectly possible to continue to access and have open a PST file and not know that some of the data has become inaccessible.
Furthermore due to the fact that they are not supported being accessed over a network, that means keeping copies of them is not really practical. You cannot store them in "Read Only" format or access directly from a CD as the file will not open. Outlook needs write access to open the file. That would mean copying the file off the read only source, changing the tag on the file and then opening it. That could cause corruption in the file.

File Bloat

Due to the way that PST files store their data, they will actually use more space than the same data in Exchange - up to three times, and that is not taking in to account the loss of single instance storage.
100mb of email can be as much as 300mb in a PST file.
If ten users were sent a 2mb file in Exchange, then it uses 2mb of space in the store. Extract to PST files that same file would use up to 60mb as each user has their own copy in three different formats.

PST Files are not an Archiving Solution

The above should be enough to know that they are not an archiving solution. If you value your data do not store it in a PST file.
If you need to keep content for regulatory reasons, then a PST file will fail on many counts, such as allowing the user to modify the item after it has been received.

Are there any reasons to use PST Files?

If you aren't connected to Exchange, then you have no option but to use PST files.

With migrations, in some scenarios they are the only option, because they are domain independent. A PST file from one domain can have its contents imported in to another domain. However the same issues with the files remain, so when using them for this type of migration caution must be taken to ensure the data remains intact. 

Conclusion

Hopefully the above will give you some idea why PST files should not be used where there is any value to the data.

Exchange 2007 Toolbox Shortcuts

A while ago I wrote a blog posting about creating a custom MMC which contained the Exchange 2007 Management Console, public folders, queue viewer and ADUC. This made them easier to find instead of going through the Toolbox in EMC. (http://blog.sembee.co.uk/archive/2007/11/06/60.aspx)

However you can create shortcuts for each of the icons in the toolbox and put them in the start menu to allow direct access.
The paths to the toolbox items are in the registry in the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\AdminTools\Toolbox

The icons, for when you create the shortcuts, can be found in this file:

C:\Program Files\Microsoft\Exchange Server\bin\Microsoft.Exchange.Management.NativeResources.dll

Create a new shortcut in the usual way, and paste the path exactly as shown. If you have installed Exchange application in a different location then you may have to adjust the path to match your environment.

Once the shortcut has been created, right click on it and choose Properties. Then choose change icon and select the icon that you want to use.

These shortcuts work on both Windows 2003 and Windows 2008 and also work with SBS 2008.

Full List of Shortcuts

Here is the full list of the toolbox items, including their paths.

  • Best Practises Analyzer
    "C:\Program Files\Microsoft\Exchange Server\bin\ExBPA.exe"
  • Exchange Performance Monitor
    mmc "C:\Program Files\Microsoft\Exchange Server\bin\ExchPrf.msc"
  • Exchange Troubleshooting Assistant
    "C:\Program Files\Microsoft\Exchange Server\bin\ExTRA.exe"
  • Database Recovery Management
    "C:\Program Files\Microsoft\Exchange Server\bin\ExTRA.exe" -AS -PS LaunchDatabaseRecoveryManagement
    (Icon available simply by pressing "Change icon")
  • Mail Flow Troubleshooter
    "C:\Program Files\Microsoft\Exchange Server\bin\ExTRA.exe" -AS -PS LaunchMailflowTroubleshooter
    (Icon available simply by pressing "Change icon")
  • Database Troubleshooter
    "C:\Program Files\Microsoft\Exchange Server\bin\ExTRA.exe" -AS -PS LaunchDatabaseTroubleshooter
    (Icon available simply by pressing "Change icon")
  • Message Tracking
    "C:\Program Files\Microsoft\Exchange Server\bin\ExTRA.exe" -AS -PS LaunchMessageTracking
    (Icon available simply by pressing "Change icon")
  • Performance Troubleshooter
    "C:\Program Files\Microsoft\Exchange Server\bin\ExTRA.exe" -AS -PS LaunchPerformanceTroubleshooter
    (Icon available simply by pressing "Change icon")
  • Public Folder Management Console
    mmc "C:\Program Files\Microsoft\Exchange Server\bin\Public Folder Management Console.msc"
  • Routing Log Viewer
    "C:\Program Files\Microsoft\Exchange Server\bin\RoutingView.exe"
  • Queue Viewer
    mmc "C:\Program Files\Microsoft\Exchange Server\bin\Exchange Queue Viewer.msc"
    (Uses the same icon as the Routing Log Viewer, so use change icon and browse to the Routing Log Viewer executable location.)
  • Exchange Details Templates Editor
    mmc "C:\Program Files\Microsoft\Exchange Server\bin\Details Templates Editor.msc"

Update March 17th 2009.
I have removed the download of the tools shortcut because of the prompt you get from Windows when trying to run files downloaded from the internet - each time you start the shortcut. You should create your own shortcuts instead.  

Account Does Not Exist Error When Appointment Sent to Another User

One of the most common questions on forums is why does a user get a NDR (Non Delivery Report) report similar to the one below when they send an appointment to another person. The NDR will reference a user who is no longer part of the company and does not have an account on the system any longer.

Your message did not reach some or all of the intended recipients.
Subject: Sales Meeting
Sent: 8/22/2008 8:54 AM

The following recipient(s) could not be reached:
Another User on 8/22/2008 8:54 AM
The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address.
<mail.example.net #5.1.1>

This is caused by delegates.
The user referenced in the NDR was a delegate on the recipient of the appointment.

However what you may find is that when you look at Delegates through Outlook, the user is not listed.
This is because the delegate system can get "stuck" and the information in Outlook and on the server are not in synchronisation.

To reset it, simply follow the procedure below.

  1. Remove any delegates that are currently listed for the user.
  2. Add a new delegate to the list. IMPORTANT - this new delegate must not have been a delegate to the user before. I will usually create a temporary mail enabled account for this process and then delete afterwards.
  3. Wait at least 30 minutes for this change to be propagated to the server correctly.
  4. Remove the new delegate from the list.
  5. Wait at least 30 minutes again.
  6. Add the preferred delegates back in to the list.

This works by replacing the complete list of delegates on the account.

If this still doesn't work then you will have to scan the domain using adsiedit.msc for references to the former user on the user's settings. I have only ever had to do that once, when Outlook wouldn't open the delegates tab. Otherwise the procedure outlined above has always worked for me.

Exchange Database Limits


There have been a number of posts on forums about the database limits in various versions of Exchange. This post is a quick summary.

The limits shown also apply to Small Business Server, which has Standard edition of the relevant version installed.

Exchange 2000 Standard Edition: 16gb *
Exchange 2000 Enterprise Edition: Unlimited **

Exchange 2003 Standard Edition RTM and SP1: 16gb *
Exchange 2003 Standard Edition SP2: 18gb soft limit, 75gb hard limit ***
Exchange 2003 Enterprise Edition: Unlimited **

Exchange 2007 Standard Edition: 50gb soft limit, unlimited hard limit ***
Exchange 2007 Enterprise Edition: Unlimited **

* Exchange 2000 and 2003 Standard edition SP1 or older, can both be increased to 17gb as a temporary measure to allow the store to be remounted to remove content.

** The actual maximum possible size of the Exchange database is 8TB, effectively unlimited.

*** Exchange 2003 SP2 and Exchange 2007 have soft limits. This is a setting in the registry that limits the database to the size shown. It can be increased as required.
The idea is to stop run away store growth. Should something happen within the Exchange setup that causes rapid store growth, it will hit this limit and be dismounted.

With this introduction of a soft limit, the way that the database limit is enforced was changed.
With Exchange 2000 and 2003 prior to SP2 the database limit was the physical size of the store. The amount of white space in the store was not taken in to account. This meant that once you hit the limit you needed to do an offline defrag of the database to get it below 16gb, even after you had removed content.

With Exchange 2003 SP2 and later, this behaviour has been changed. The limit is now the physical size of the store, minus the amount of white space. Therefore if you hit the physical limit of 75gb on Exchange 2003 SP2 then an offline defrag is not going to help. Users need to actually remove content to create white space in the store.
Furthermore the database size is not checked in real time. It is checked once a day, by default at 5am (this can be changed via a registry modification). Therefore if the store dismounts because the limit has been breached, you can simply restart the service and the store will mount again.

However in my experience, once you hit the limits, even removing the content will only be a temporary solution. Either an investment needs to be made in an archiving solution that actually removes the content from the store, or an upgrade to Exchange 2003 Enterprise edition or Exchange 2007 Standard needs to be carried out.

Relevant Links at microsoft.com

Exchange 2003 Limit Changes: http://technet.microsoft.com/en-us/library/aa998066.aspx
Exchange 2007 Limit Changes: http://technet.microsoft.com/en-us/library/bb232092.aspx

Increase the limit of the Exchange 2000 database to 17gb: http://support.microsoft.com/kb/813051

Massive SBS Server and Network Cleanup

Something I have been doing frequently for the last 18 months of so is cleanups of SBS 2003 servers and their associated networks. I have a number of clients in the IT Support industry who ask me to clean up their client's servers. Two of them get a new client and the first thing they do is ask me to look at it and make recommendations.

In many cases it is minor cleanups or ensuring that everything is up to date. However one that I have done just recently deserves a blog posting on its own.

Background

New client for one of my IT Support clients.
They said that their client didn't think that there had been much maintenance done by the previous support company and the AV had expired. They were also looking to use Windows Mobile devices but were having problems getting it to work.
It had already been agreed to deploy AVG, so I was asked to look at the site and report what was required.

Seven users, one server, low level of email use apparently. Old school was the phrase that was used to me when describing the company.

I was shocked, to say the least.

Server

SBS 2003 RTM.
Thankfully I was sitting down when I saw that. No service packs, no automatic updates nothing.
DHCP was being run by the router, not the server.
DNS wasn't configured correctly.
The AV had indeed expired - 18 months ago. It was Symantec as well.
POP3 connector for email collection
Most of the wizards hadn't been run correctly.
Various other bits of junk on the server
The backup wasn't configured correctly, therefore the Exchange transaction logs were building up. There were four years of transaction logs.

Clients

I was able to get on to one of the clients.
Windows XP SP1
Office 2003 RTM
Same expired Symantec AV.
Adobe Acrobat Reader 6 (remember that?).

It was like the site was stuck in 2004. The site was deployed and never touched afterwards.

Anyway, I like a challenge.
Did I mention that the site was 350 miles away, and I was working on it remotely?

The positives?
I tried.
8mb ADSL getting 5mb on the bandwidth tests, which was ok. Plus it had a static IP address. The server had lots of space on it, it was a good configuration, multiple arrays, 2gb of RAM. It was a Dell system and the original suppliers had obviously installed it fresh as it didn't have the Dell issue of a 12gb root partition. However the rest of the server hadn't been done correctly.

So what did I do?

To begin with, over a course of two nights in the week, I downloaded the updates I needed

Windows 2003 SP2
Exchange 2003 SP2
Windows XP SP2 and SP3
SBS SP1
SharePoint Service Packs
WSUS 3.0 SP1
Office 2003 SP3
AVG Admin and the main Application
Adobe Acrobat 9.0

I asked my client to purchase an SSL certificate credit from https://DomainsForExchange.net/
I also asked for access to their domain name configuration, and web site.

Finally I asked that all the workstations be left on over the weekend and a tape left in the backup drive.

Before I started, I corrected the backup job.
This not only provided me with a backup of their data, it also flushed out almost 15gb of transaction logs, which made the server a little more snappier. Once the job was finished, I ejected the tape as a precaution.

With a successful backup, I could then begin the real work.

I started off by flashing the router firmware to the latest version, then reviewing its configuration.
Then started on the server, downloading the latest BIOS and drivers.
Windows Service Pack was first, then the driver updates.
Rest of the service packs as required, concluding with the WSUS installation. I then set that to sync and started on the workstations.
Symantec AV was removed and the AVG installation was setup and configured, ready for installs on the clients.

I moved the data around on the server as per the best practices.
Using the SBS Best Practises tool, cleaned up any issues that flagged and reset the backup job to backup correctly. 

Each workstation had the Symantec AV removed, the Adobe Acrobat removed and then was brought up to SP3. Rebooted as required.
Office 2003 service pack installed along with the new version of Acrobat Reader.
The workstations also got updated BIOS and drivers.

AVG was installed on the systems, updated and a full scan carried out.
They were very lucky. While a few things were found, they were not serious and

I setup the client with an OpenDNS account and changed the configuration of the server to use that. DHCP was removed from the router and moved to the server. However before I did that I carried out an IP Address scan and found a network printer. A nice HP LaserJet. Fortunately it was configured by defaults, so I was able to connect to it, update its configuration and firmware. Then downloaded the latest drivers from HP and installed them on to the server and shared the printer from there. On each client the printer was changed from direct to the shared printer.

The SSL certificate was deployed with a real name following some DNS changes, and the relevant port opened on the firewall (443). Yes I know SBS can do that for me, but I needed to retain control.
Configured a split DNS system so that the external name on the SSL certificate also worked internally.

I also downloaded and installed PRTG Traffic Grapher and configured that on the server to look at the router. Created a mini admin web site on the server, with PRTG on a web page, along with the AVG status page and a web page to manage the IMF quarantine emails.

By this time WSUS had synchronised, so a few group policy changes had the client talking to that. I ran a few scripts on the client to get them to call in correctly, then left them to download their updates for a few hours.

Once the updates were in and installed, and the systems rebooted, close to finishing.
Secured the server for SMTP email and then changed the MX records to point to their static IP address.

Tested Exchange ActiveSync from outside, along with RPC over HTTPS, OWA and confirmed it was working.

Finally set all systems to defrag. 

There were also a lot of very small changes that I do on every site which are simply too numerous to list (plus I can't remember them all).
I was also available on Monday morning for any issues that came up - there were none.

Rough tests on start up times of the server and workstations showed that I halved the time they took to start up.

The job took most of a weekend and basically involved three or more years of maintenance being done on the network in that time. Once it was complete I dropped an email to my client with a list of what I had done (pretty much what I written above), recommendations for future work and a bill for £2,000.

Probably the best bit was the feedback from the end users. It felt like they had a new network, everything worked, faster, things we where they should be etc. Overall everyone was very pleased.

Ultimately, they were lucky. As they had a router and their email traffic was so low, they didn't get hit by anything major that would have caused a problem. They were badly exposed though and if something had got in then it would have run amok.

The Sales Pitch

If you are in the UK and either a direct user of SBS or are supporting SBS Servers, then I can do something similar for you. Server cleanups start from £250 (+ VAT) depending on the work that is required. I will look at the server and tell you what is needed and quote on that basis. Additional bits (like SSL certificates, AV licenses etc) need to be purchased separately.

If you are a support company, then this type of work can give you a quick win and provide you with an immediate impact with the client. The simple change from POP3 connector delivery to SMTP delivery is normally enough, without the other background work.

In the vast majority of cases, this work can be carried out remotely, out of hours. It does not require a site visit, simply remote access is required (Log Me In is my preferred method).

Similar work can be carried out on the full product over multiple servers.

However, here is the interesting bit… the financials.
The client who I did this job for was prepared to buy additional hardware and software from their previous support company to resolve the problems - which the previous support company had caused by not doing the maintenance correctly. Someone suggested getting a second opinion, and that has saved them money. Their original outlay will now be fully utilised and they will see benefits. Since that work was carried out in mid September they have started to use Windows Mobile, and are now looking at laptop use. Productivity has increased - simply by investing some time in their existing infrastructure, rather than purchasing new and going through the headache of a migration. Despite everything I did for them, Monday morning they were able to come in and start work immediately, with no significant impact on their business, other than the "wow" factor.