Exchange Server password expiry handling on iPad/iOS 5

Overnight, the password for my Exchange account expired, as would be expected in line with my security policy.

Unfortunately, it would appear there is a bug in iOS 5′s handling of this situation. My iPad (running iOS 5.0.1) had many, many “incorrect password” prompts when I picked it up to use it this morning. There were so many that I was about to concede that the iPad as unusable until I found a computer to change my password on, as the password was yet to be set to a new value.

I would usually change my password directly from the iPad, by logging in to OWA, where I have enabled the ability to change a password when it has expired.

After some time of pressing “Cancel”, I was finally relinquished from the grasp of this prompt and was able to proceed to use the iPad normally.

It would appear to me that the number of prompts would be equal to either the number of Fetch attempts since the password expired and/or the number of occasions the iPad has tried to open a session for push delivery from the server. Of course, the iPad would have failed on every occasion, and it would appear it is being extremely verbose by displaying each and every failure.

Either way, the code should detect an incorrect password and show the “Incorrect Password” pop-up once only, as was the behaviour I experienced on iOS 4. If I choose to dismiss that message, I should not be repeatedly prompted with the same alert. As a tech savvy user, I repeatedly hit “Cancel”, but many of the users I deals with on a daily basis would try this a couple of times and then assume their iPad was unusable and not continue for fear of “breaking” something.

It seems I am not the first to come across this issue, but I will add my voice to those who hope this issue is resolved in a future iOS release.

For Exchange and AD admins, be aware this issue could potentially lead to lockout situations, dependent on your security policies.

Experts Exchange and WaterRun in Ethiopia

Hi fellow readers!

My apologies for not posting much new over the last year or so! I can’t believe it has been 11 months since my last post, but I guess time really does move that quickly. I can assure you I have been tremendously busy, and I will endeavour to update you when I get a few seconds.

In the mean time, I have some very exciting news to report. Experts Exchange, the knowledge sharing site on which I am a very active member, recently contributed to a fantastic community project: the building of water wells in two communities in Ethiopia.

As part of the ‘EE T-Shirt Charity Challenge‘, the Experts with too many shirts for their wardrobes asked EE to donate the cost of those shirts to charity. EE happily obliged, and we donated many hundreds of t-shirts to a very worthy cause. The EE staff at the offices in California decided they would help too, so ran their own charity luncheon to raise funds for the second well to be built.

In conjunction with WaterRun, the EE community is pleased to announce the wells have been completed and are now providing safe, clean, unpolluted drinking water to two communities in Ethiopia. A resource I take for granted has changed the lives of some of these people. A real measure of community is how it can contribute to issues in the outside world, and I believe this is one brilliant example of the Experts Exchange members pulling together to help a very good cause.

Thanks to all involved. This is remarkable.

The following link will take you to the EE Corporate Blog, where the project is explained in more detail.

I helped bring clean water to Ethiopia

Exch 2010 SP1 with AirSync (iPhone/iPod/iPad)

Over the last couple of days, I took the time to upgrade my personal Exchange environment to Exchange 2010 SP1 Rollup 1 (I was on 2010 RTM). The update appeared to go without a hitch, but a day or so later, I discovered my iPod (in fact, this is true for any Apple iWhatever device) wouldn’t sync mail over the air via EAS, it wouldn’t send email and OWA replies/forwards failed with ugly error messages.

If you’re seeing any of the following errors just after upgrading to SP1, you might find the root cause and the associated fix is very simple – if so, read on.

  • An error occurred while delivering this message
  • This message has not been downloaded from the server
  • Cannot Get Mail – the connection to the server failed
  • In OWA: An unexpected error occurred and your request couldn’t be handled
  • In event traces, imceaDomain must be a valid domain name.

Now, this issue was picked up and discussed in the release notes for 2010 SP1 as a known issue, but I didn’t clock this initially because I didn’t exactly read the notes thoroughly – a brief scan, perhaps, late in the evening, but nothing looked relevant on my tired eyes at the time. I’ve also already performed a number of SP1 upgrades elsewhere without experiencing issues, so I didn’t consider it important to refresh my memory by re-reading the notes.

The exact symptoms:

On the ActiveSync device:

Your email will sync, but there won’t be any content. The preview of the message text will display in the folder view, so you know something is there, but expanding the message to actually read it reveals the message: This message has not been downloaded from the server. Scrolling down, you can use the button to download remaining content – but it claims the message is 0 bytes in size and pressing this doesn’t do anything.

 

Message view - the messages just don't download

 

Sending email from the device resulted in a message: “Cannot Send Mail. An error occurred while delivering this message.” Unfortunately, all the errors issued by the Apple kit are fairly generic (probably because, in this instance, it didn’t actually know what the problem was – but I’m inclined to think it’ll always make you dig to find the root cause).

Non-Exchange accounts, such as Gmail, and potentially accounts on other Exchange environments configured differently to avoid this bug, worked absolutely fine.

Via OWA:

OWA, again, reports a generic error:

Expanding the details in the error or looking in your server’s event log, reveals an interesting exception message:

Exception message: imceaDomain must be a valid domain name.

If you’re not familiar with IMCEA (Internet Mail Connector Encapsulated Address), it was originally a method of inter-connecting mail environments by providing temporary addresses to users sending email via SMTP, but did not possess an SMTP email address. The mail system handled the encapsulation and subsequent reverse process in order to send and receive email for the user. The technology is still used today in the latest versions of Exchange, and you will often see cases where an SMTP address is unknown, so an IMCEA version of an X.500 address is displayed – often in NDR reports. According to Technet, Exchange actually uses IMCEA encapsulation for any address other than the default authoritative domain.

In this case, Exchange is having issues dealing with just that – the default authoritative domain. You see, if the friendly name you gave it has a space in it, or some other illegal character for a domain name, it triggers an error in the programming, which ultimately leads to this major loss of core messaging functionality.

As always, the fix is fairly simple. Remove any spaces from the friendly names of your accepted domains. You can do this at shell or the console – I prefer using the shell, in which case, use

Set-AcceptedDomain “Friendly Name of your default authoritative domain” -name “AnyNameWithoutSpacesOrIllegalCharacters”

Once the name change is complete, throw a restart on the MS Exchange AD Topology service during a period of planned system outage and functionality should come back. I pick that service because it restarts most of the others at the same time.

As a result of this issue, I will be forcing a new naming convention everywhere I manage Exchange, whereby accepted domains are ALWAYS named after the actual domain name for ALL accepted domains, thus containing no spaces and no other illegal characters. It transpired that the other sites were named in this fashion for the default domain anyway, which explains the reasoning as to why I never experienced this issue with those users.

Missing some cmdlets at Exchange Management Shell? Me too!

On one of our many Exchange Servers at work, I recently discovered the Exchange cmdlets in the Management Shell which I rely on for my daily Exchange management had disappeared. get-excommand reported just one Exchange cmdlet was loaded: Get-ExchangeDiagnosticInfo. Strange. They were there one day, gone the next. No, it wasn’t caused by an update to the best of my knowledge; it didn’t happen over our patching window.

The case of missing cmdlets was traced back to an issue with my user profile on this server. A test with another user account yielded no issues at the Management Shell.

A quick fix to this might be to obliterate the user profile using the System applet Control Panel, then log back in and have Windows generate a new profile. However, this is totally unnecessary and you’ll lose any special configuration, given how simple the actual solution is.

Exchange Management Shell uses a directory in the user’s roaming Application Data to store the Powershell module configuration settings. My module data had some… modifications. I don’t know the source of these changes, but it rendered the cmdlets missing. I suspected this was the case because shell loaded much more quickly than normal when it was broken – rather than show the status of the pending implicit remoting session, which I am used to seeing, it loaded and connected almost instantaneously.

The solution is to remove the C:\Users\username\AppData\Roaming\Microsoft\Exchange\RemotePowershell\your.domain.com directory.

After deleting this directory, restart the Shell. The startup process will create the directory and re-generate the module files, fixing your issue and allowing you to get on with whatever you needed to do!

Matt

P.s. I know I’ve been quiet lately, and for that, I apologise. For the past couple of months I’ve been involved in an almighty migration job, away from an awful managed service network (tip: NEVER opt for an outside company to supply your network. It falls apart!) to a vanilla Windows Server system. This came not a moment too soon but completing a migration of this magnitude for 2500 seats in the 6 week maintenance window is no easy feat!

I do have some articles on the backburner, and hope to get some out to you ASAP. Thanks for your patience, and thanks for reading!

Windows XP Favourites Redirection – ADMX files

One of the major disadvantages of still running XP in production is its lack of Internet Explorer Favourites directory redirection. If your users frequently roam between computers, the usual workaround is to enable Roaming Profiles to have the favourites roam with them. This usually works, until Windows Vista or 7 is introduced into the environment.

The newer Microsoft operating systems from Vista onwards do not support the old, legacy format of the XP profile. Instead, users logging on to a modern OS for the first time will be given a new roaming profile with “.V2″ appended to their username in the roaming profile share. This is the version 2 profile, used by Vista up and totally isolated from the XP profile, including total isolation of the data it contains. In a phased roll-out of the newer Microsoft operating systems, you must follow best practices by using folder redirection to redirect user data on all systems to a common network location. This removes the data from the profiles, maintains consistency and ensures the user experience is the same on all network stations, without concerns over which OS is installed and therefore which profile and data the user will have access to. Plus, roaming profiles are just too slow for storing lots of user data anyway.

Unfortunately, Windows XP does not support redirection of the Favourites directory; this support was added in Windows Vista. One workaround I have seen is the built-in Vista redirection configured to redirect user favourites folders on newer systems to the legacy XP roaming profile share. This works, but it’s not particularly clean; redirecting data to a profile share rather than a user (home folder) share just isn’t right. It also causes data loss issues if a user’s profile must be reset; I work by the principle that only disposable data – stuff the users could live without – should be put into a user’s profile for precisely this reason.

Implementing Favourites redirection in Windows XP is a logical alternative; it isn’t particularly difficult either. I developed the following ADMX files to supplement the older ADM solutions which are available through a search on a popular web search engine. With 2008 or 2008 R2 Domain Controllers, the ADMX format is available for your use and I would highly suggest you make use of it. ADMX is XML-based and much, much easier to use than the legacy ADM language.

XPFavouritesRedirect.admx

<policyDefinitions revision="1.0" schemaVersion="1.0">
  <policyNamespaces>
    <target prefix="customFavorites" namespace="Microsoft.Policies.Favorites" />
    <using prefix="inetres" namespace="Microsoft.Policies.InternetExplorer" />
  </policyNamespaces>
  <resources minRequiredRevision="1.0" />
  <supportedOn>
    <definitions>
      <definition name="SUPPORTED_IE5" displayName="$(string.SUPPORTED_IE5)" />
    </definitions>
  </supportedOn>
  <policies>
    <policy name="IE_Favorites" class="User" displayName="$(string.IE_Favorites)" explainText="$(string.IE_Favorites_Location_Explain)" presentation="$(presentation.IE_Favorites)" key="Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders">
      <parentCategory ref="inetres:InternetExplorer" />
      <supportedOn ref="SUPPORTED_IE5" />
      <elements>
        <text id="IE_Favorites_Location" key="Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" valueName="Favorites" required="true" expandable="true" />
      </elements>
    </policy>
  </policies>
</policyDefinitions>

XPFavouritesRedirect.adml (name this the same as the ADMX file and dump it in the language folder in your PolicyDefinitions directory)

<policyDefinitionResources revision="1.0" schemaVersion="1.0">
  <displayName>
  </displayName>
  <description>
  </description>
  <resources>
    <stringTable>
      <string id="IE_Favorites">Location of Internet Explorer Favorites</string>
      <string id="IE_Favorites_Location">The path to the favorites folder</string>
      <string id="IE_Favorites_Location_Explain">Specify the path to the location of your Favorites folder. This is stored in an expandable registry string value, so you can use environment variables, such as %HomeDrive%%HomePath%.</string>
      <string id="IE_Favorites_Location_Tip1">Specify the UNC path to the favorites location</string>
      <string id="InternetExplorer">Internet Explorer</string>
      <string id="SUPPORTED_IE5">at least Internet Explorer v5.01</string>
    </stringTable>
    <presentationTable>
      <presentation id="IE_Favorites">
        <textBox refId="IE_Favorites_Location">
          <label>Path:</label>
          <defaultValue>
          </defaultValue>
        </textBox>
      </presentation>
    </presentationTable>
  </resources>
</policyDefinitionResources>

The above is standard ADMX/ADML format which can be dumped in the correct locations of your Central Store (if you don’t have one, why not? Set one up, otherwise you will need to store them in the local store on each DC). In the GP Editor, it will appear as a policy in the standard Internet Explorer area under the User Configuration / Windows Components node.

The Favourites registry value in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders is of type REG_EXPAND_SZ. The ADMX implements this with the expandable=”true” syntax, meaning from your perspective, you can specify environment variables in the GPO and these will be properly expanded by the system to their full paths. I personally use %HomeDrive%%HomePath%\Favourites to direct them to a subfolder of the user’s defined home folder location in their Active Directory user account properties.

This does not move any existing Favourites out of the profile and into the redirected location. However; this is fairly easy to script in a logon script or one-time operation. For new users, the Favourites directory will be created automatically, assuming the home drive exists, the user has permissions, quota is not fully used and so on.

It is a good idea to set the XP Favourites redirection policy in its own GPO object, then apply a WMI condition to filter the policy to XP/2003 and older systems only. Windows Vista and above support native redirection of Favourites, so you should use a separate, WMI filtered policy for Vista+ computers to redirect their Favourites to the same location as defined for XP clients.

APC Powerchute vs. Windows Power Management

I was recently trialling APC Powerchute on a small SBS 2008 server, attempting to maintain some automated shutdown while also gleaning some stats on how frequently the UPS was intervening. I’ve used the software before, but this time it refused to play ball; I saw the stats, but it never shut the server down on power failure. Not good; I’d rather know the data was safe than be told how many times it wasn’t safe.

So, I reverted to the fallback option. An APC UPS (the USB connected ones, not sure about serial) can run under Windows’ power management, being configured and monitored in exactly the same way a battery in a laptop would. Thus, they truly are plug-and-play; some less reputable brands require their own monitoring software and aren’t nearly as effective in my experience.

Alas, uninstalling the software never restored Windows Power Management. I waited… rebooted… checked control panel… nothing. No mention of a battery in the power options and the power meter icon was disabled in the task tray. I’d lost all shutdown functionality from the UPS. Yet again, a routine job involving a computer turned in to a match of man vs. machine.

The fix was surprisingly simple, didn’t involve edits to the registry (which I fear when it comes to drivers and hardware and critical things like power) — but unintuitive:

  1. Open Device Manager, expand Batteries, locate the UPS and uninstall it. Be sure to uninstall the driver too when asked
  2. Wait a few minutes for that to complete, then on the Action menu, hit Scan for hardware changes
  3. Sure enough, the UPS was detected again, the drivers installed fresh and my power icon in the task tray immediately restored

It would appear APC Powerchute doesn’t fully tidy up after itself.

In the UK? Want an @gmail address? Now you can!

Just want the answer? See below

Although I run my own personal Exchange Server at home, I also run a couple of Google Mail accounts for subscriptions to online forum sites, newsgroups and suspect sites I might be required to sign up to occasionally. I’ve been caught in the spam trap before and I’m triply cautious not to share my main email addresses with anyone I don’t trust. Maybe I’m just overly cautious… but an email address is something you should treasure.

When I used Gmail for the first time, it was obvious Google had it right: for a free mail service for the average home user, it just works. You’d be hard-pressed to use all your 7.5GB mailbox quota (an ever increasing figure) and features like conversation view (recently introduced in Outlook 2010, thank you!), labels and archiving are handy.

However, I was never impressed by the email domain I received. Other parts of the world had the privilege of @gmail.com, yet a registration attempt from the United Kingdom for the past few years forced the longer googlemail.com at me. my alias@gmail.com still worked, but outgoing email and Google themselves still used the longer name.

You might ask: Why?

The answer goes back to a trademark dispute with an agency in the United Kingdom in 2005, which forced Google to drop gmail.com for new UK registrations. The webmail site was also rebranded for UK users with different logos. However, Google and the other party agreed to settle the dispute for £228k in 2008 and the rebranding back to gmail.com is now taking place.


I’m an existing customer. How do I get my @gmail.com address?

If you currently have a googlemail.com email address and want to use gmail.com as your “primary” address for sending mail from, you’ll need to convert it. Ironically, I hadn’t heard about this story until I accidentally stumbled upon it in Google’s Settings and I’d wager many, many users are in a similar position.

To claim your address, log in to Gmail, click Settings in the upper-right of the browser window, then select the Accounts and Import tab. Choose the Switch to @gmail.com option to begin the process. Per typical Google fashion, it’ll take you a matter of seconds.

Choose "Switch to @gmail.com" to claim your new email address

Choose "Switch to @gmail.com" to claim your new email address

Rest assured your @googlemail.com alias will still exist and be routable; you won’t need to re-register with any sites or send out mass “I’ve changed my address” messages to anyone who currently reaches you on that address. However, any mail you now send will come from you@gmail.com, not you@googlemail.com, a significant improvement in my opinion!

Thanks once again, Google!

Exchange 2010 SP1 Announced

Was it really 7 months ago Exchange 2010 RTMed? I find that incredibly hard to believe, but true. Today, the blogosphere heated up following the Exchange Team’s announcement of the first Service Pack for the latest and greatest version of Microsoft’s Exchange email server.

The team suggest Beta code will be available for your test environments later in the second quarter of 2010, sometime around June. Although I have no quibbles with Exchange 2010, the product group has still found places to make some useful improvements:

  • Outlook Web Access (OWA) – performance improvements using more Web 2.0 AJAX-style programming, usability improvements and prettifying through the re-introduction of themes.
  • Archiving and Compliance – My clients will benefit significantly from the ability to separate an archive mailbox from the user’s main mailbox – even to different mailbox stores. Frankly, server-side archive support was a long-awaited replacement to the problematic PST file or third-party tools, but moving data around within the same store just made no sense and we held off enabling the feature.

    Users with local Outlook AutoArchive PST files can also have their PST data imported directly into their Archive mailbox. With a bit of luck, we’ll begin to see many more PST free establishments.

  • EMC/ECP Improvements – minor improvements are being made to the GUI management tools, negating the requirement for you to drop to Powershell for some configuration tasks.

Not mentioned were any bug fixes, although I suspect there will be a few. With a little hope, my pet hate – the preferred Global Catalog issue when creating and mounting a new Mailbox Database – will be resolved.

The Exchange Team have done a stellar job with the 2010 release so far and, unlike Exchange 2007, no real areas are lacking in functionality. However, there is always room for improvement and I look forward to seeing Beta code to play with later in the year!

See the full press release on the MS Exchange Team blog

Demystifying the Active Directory FSMO roles

If you’ve spent any time administering Active Directory, you’ve probably come across the concept of Flexible Single Master Operations (FSMO) roles. Their introduction is arguably one of the most important but misunderstood changes to Active Directory in the last ten years.

Take a trip down memory lane

In the days of Windows NT, one may recall the Primary Domain Controller (PDC) and Backup Domain Controller (BDC) concept. The directory was structured such that every DC, whether a PDC or a BDC, had a copy of the directory database, but only the PDC could make changes to that database. The model was inefficient, negatively impacted growth and desperately needed improving if the product had any chance of surviving.

Enter Windows 2000. The Directory Service went through one of its largest scale rebuilds to date. Replication and management was significantly improved and the concept of having a multi-master directory was introduced. Although this design has been tweaked over the years, fundamentally, it has remained the same through the versions – because it works. Any DC anywhere in the domain can execute virtually any update to the directory. This scales beautifully, even on large, geographically dispersed networks with many thousands of users.

However, notice I said virtually any change. Since a change can take effect at any DC, there is the possibility that a conflicting change will be made in two locations concurrently – or before replication can occur. Active Directory must ensure these situations are accounted for. In most cases, it applies its complex Multimaster Conflict Resolution Policy, which essentially says the last change wins. However, there are several procedures which simply cannot conflict; these procedures are assigned to one of the five FSMO roles, which go on to be delegated to one or more Domain Controllers.

What are the FSMO roles?

There are nominally five roles present in the directory which reside on DCs nominated specifically by the Administrator to perform these tasks. All the roles are very important and constitute a single point of failure in all Active Directory enterprises. If you have a complex topology with more than one domain, some roles are domain-specific, so you can expect to have duplicates of some roles in every domain in the enterprise.

  • The Domain Naming Master exists once per forest – in the forest root domain – and is rarely used. It is responsible for processing the addition of new child domains, application partitions and external cross-references to the enterprise. Since the name of a child domain or application partition cannot be duplicated (it would conflict in DNS, let alone send Active Directory around the twist), the DC holding this role is the only DC with the ability to process all additions of this kind in the forest.
  • Infrastructure Master: If a user from a foreign domain within the same forest is added as a member of a compatible group in another domain, the DCs in the group’s domain must have some information about that user in its local database in order to update the member attribute of the group. To do this, it adds a special record to its database called a phantom, which contains only the foreign user’s security identifier (SID), globally unique identifier (GUID) and their distinguished name (DN). Like all objects in the database, this record is given a distinguished name tag, or DNT, an internal reference used solely in the low-level Active Directory database layer. In doing this, the directory service is able to add that user as a member of the group by referring to the phantom’s DNT, just like it would refer to a user’s own DNT if you added a user from the group’s own domain to the group. You might think of this like using a primary key in a relational database to refer to objects across tables, but not exactly, as Active Directory’s database is by no means any sort of RDBMS.

    That’s very clever, but what if something about the source user in their original domain changes? If the user is renamed, moved or deleted, the phantom in the group domain DC databases would lose its referential integrity with the source domain. This is a situation the infrastructure master aims to avoid. On a periodic basis (by default, every 2 days), the infrastructure master – an FSMO role present in every domain – compares its local database to a Global Catalog (GC) server to determine whether any changes have been made to the objects the phantoms were created to represent. A GC contains a partial replica of all objects in the forest, so replication means any GC would already know about this updated data. The phantom is then updated with new values or deleted from the domain’s database if the object has been removed from its source domain.

    In a multi-domain forest, you must either locate this role on a Domain Controller which is not a Global Catalog or, if you must locate the role on a GC, ensure all DCs in that particular domain are GCs. A GC will never create phantoms because it already knows about users from other domains. If the infrastructure master is a GC, there will never be any phantoms in its local database to compare with the global catalog data, so no updates will be made, but other non-GC DCs in the domain would gradually become outdated. If all DCs in the domain are GCs, or you only have a single-domain forest, every DC knows enough about the security principal that it does not need to create a phantom, so this role is essentially redundant.

  • Schema Master: As the name suggests, this role is the Master of the Schema, the information which contains the formal definitions of how Active Directory stores objects, what attributes are available on those objects and so on. This role exists once per forest, on a DC in the forest root domain. Any updates to the Schema must be tightly controlled, so one DC delegated as the Schema Master performs all such changes to the database. Schema updates are then replicated to other DCs on the network by standard Active Directory replication.

So far, three of the five roles have been covered. Those above are those I would consider the least critical FSMO roles in the forest. If you lose the DC delegated one or more of these roles, it’s no big deal — it may prevent a network administrator taking an action, but it will not impact the usability of the network. Losing the Domain Naming Master or Schema Master would create problems in regard to creating child domains or running schema updates, but these generally occur very rarely and checking this Operations master DC is up would be part of the planned engineering works. Similarly, losing the Infrastructure Master may cause integrity issues in the database, but given that it only runs its scan every two days in the first place, a day or two of outage will not generally cause an issue.

  • RID Master: This role is one of the two which are important to the daily operation of Active Directory. Under the glossy GUI of Windows, security principals are identified and differentiated by use of two values – a Security Identifier (SID) and a Globally Unique Identifier (GUID).A SID is an alphanumeric string which is unique throughout a forest. The SID is the actual value used internally by Windows to identify users and grant access to resources using Discretionary Access Control Lists (DACLs), for example, via the ‘Security’ tab on a file or directory. Have you ever deleted a user, recreated her, then wondered why she cannot access the same files and folders, despite having the same username? The new account would have a new SID and is therefore considered an entirely different security principal to the system.Contrary to popular belief, the username, distinguished name or full name of a user are not internal tracking mechanisms within Windows as all these values could change.The standard make up of an SID might be as follows (this SID is purely random): S-1-5-21-789336058-1123561945-725345543-10823.The nature and formation of an SID is beyond the scope of this article, but it is the very last octet (in this instance, 10823) we are interested in. This figure represents a Relative Identifier (RID), an incremental value which actually makes the SIDs unique within a domain, ensuring no two users conflict in the database. When a security principal (user, computer, group etc.) is created, the domain SID (in this instance S-1-5-21-789336058-1123561945-725345543) has the next available RID appended to the end.Each Domain Controller is initially allocated a pool of 500 RIDs. As security principals are created, RIDs are used up. The allocation of RIDs to DCs is a task delegated in the RID Master FSMO role to one DC in a domain. Placing the operation in an FSMO role ensures no DC obtains a duplicate RID pool, which would eventually lead to conflicts in SID values and a major problem in terms of SID-uniqueness within the domain.
  • PDC Emulator is the most complicated and least understood role, for it runs a diverse range of critical tasks. It is a domain-specific role, so exists in the forest root domain and every child domain. Its original conception was for backwards compatibility with legacy systems, such as Windows NT BDCs. However, the role is also responsible for keeping the domain time in sync, given that the DC holding this role in the forest root domain is the most authoritative time source in the forest. Password changes and account lockouts are immediately processed at the PDC Emulator for a domain, to ensure such changes do not prevent a user logging on as a result of multi-master replication delays, such as across Active Directory sites.It should be noted that the PDC Emulator does not act in the same fashion as a PDC on a Windows NT network. Cast your eye back to the top of this article and note the section regarding a multi-master directory — for multi-master aware applications, most updates can be made at any DC on the network. However, if an application (or Operating System) is not multi-master aware, the PDC Emulator acts as if it were the PDC on the Windows NT network. One of these older applications would most probably single out the PDC Emulator and write all its changes there.

The latter two roles are much more crucial to the daily operation of the network and could very quickly become a limiting factor in its growth, usability or even the logon process if the DC(s) holding the roles are offline for any period of time. If the RID Master is lost, impact will only be felt by the Network Administrator if a DC depletes its pool of RIDs. On busy networks, this could potentially occur in a matter of days through the creation of new security principals. However, loss of the PDC Emulator could directly affect your users — you’d better have a substantial help desk ready for a spike in call volume if this DC is down for an extended period of time. For example, with the most authoritative source of time unavailable, time skew could eventually occur between DCs and computers in the enterprise and/or domain, lending itself to Kerberos authentication errors and ultimately, failed logons. While it would not be an immediate issue to take this server offline (provided you do not have any legacy applications), this would be the role I would be most concerned about in the event of a DC failure.

Conclusion

If you are still reading, well done! This article covers several aspects of Active Directory in detail, including low-level database processes unseen at the surface – particularly via the GUI. However, FSMO roles are a crucial component of your deployment — having an understanding of the underpinning concepts will help with their placement, deployment and high availability concerns within your enterprise.

Why you shouldn’t use PST files

They have been around for years and for thousands of Microsoft Outlook users and email administrators out there, they’d be lost without them: Personal Storage Table (PST) files. If you’ve worked with Outlook for very long, the name will immediately ring a bell; if you’ve ever administered Outlook, you may already know about the problems associated with this notorious file format.

In any corporate environment – or, for that matter, any environment with an Exchange Server – the use of PST files as a permanent solution to an email administrator’s problems should be banned. Let’s find out why.

Problem 1: File Sizes and Data Security

The number one issue with the PST format prior to Outlook 2003 was that it was ANSI (American National Standards Institute)-based. The ANSI PST format has a maximum size limit of 2GB, and other limitations exist with regard to the number of items which can be stored per folder. However, there was a particularly problematic bug in the Outlook software which allowed data to be written to ANSI PSTs past the 2GB limit without warning. This would result in data loss, at least past the 2GB limit, but potentially loss of all the data stored in the file.

To address these concerns, Outlook 2003 and higher introduces a new PST format which runs on Unicode instead. This format stores up to 20GB of data, but it should be noted that upgrading Outlook does not automatically upgrade any PST file(s). This must be completed manually, by creating a new Unicode file and transferring the data across.

Despite the improvements made, PST files are still susceptible to corruption issues – which will result in lost data. These become particularly prevalent as files become larger or you increase the volume of data which moves through the file. For most users, the prospect of losing precious or business-critical emails, reminders, tasks and contacts could be cause for significant concern. It shouldn’t come as a surprise that you should make a regular backup of your PST file(s), but this is not completely safe, as a PST can go for weeks or months in a partially corrupted state before you realise you have a problem.

Problem 2: Network Access and Backups

PST files must be stored on a local hard disk. Accessing them over a network is not supported by Microsoft. Instabilities in the network, loss of network connectivity, speed issues in reading and writing from the file server can all cause issues — particularly for sensitive PST files, which are so very easily corrupted.

This has two implications for system administration:

Firstly, backups are already difficult to maintain, due to the issues with corruption going undetected, but will become ever more difficult to implement. As the PST cannot be run from the network, you must configure backups on each machine individually – and must ensure the backup does not run while Outlook is running. Backing up the Exchange Server is rather pointless, as the data is offloaded into the PST when the user logs in.

Second, your cost of administration increases significantly. Considering a typical organisation, which may have remote workers and several sites across different areas of the country or perhaps throughout the world, moving administration away from the server and towards the client lessens the design principles surrounding central administration, requiring more admin time to perform repetitive tasks on PST files. The system may quickly grow beyond your control, becoming exponentially difficult to track and maintain.

Problem 3: File Sharing and Remote Access

PST files do not natively support file sharing between multiple users simultaneously. If you attempt to configure this, the mail file may be corrupted — not to mention the fact you would need to run the file over the network, so problem #2 has already been invoked.

Storing data in PST files also has no benefits for remote access either. Exchange’s Outlook Web Access (OWA) (or Outlook Web App, in Exchange 2010) allows users to remotely access their mailboxes, providing a near Outlook user interface for doing so. Data in PST files has usually been removed from the mailbox, so immediately becomes inaccessible to the user remotely.

Problem 4: Inefficient use of resources

You’ve invested in a powerful Exchange Server. It: has large, redundant disk arrays, processing power and RAM capacity; cost you thousands to purchase the hardware and software licenses; adds significantly to your energy and data centre cooling bill. If PST files are in use, your server is essentially going to waste; the functionality of the server you are actually using is essentially the same as a free Linux mail server distribution running on an old workstation supporting POP3 clients.

But…

Despite the considerations above, you might still be wondering how to work around those common problems which PST files are oh so convenient for solving.

Use 1: Archiving

This is a mis-conception, brought about largely by Outlook’s desire to continue annoying its users with AutoArchive prompts. There is no reason whatsoever that mail should be archived to each user’s local PC. Consider the actions you would take to archive files off your file server; where would you put the archived data? On your own PC? On your manager’s? On the CEO’s? You’d do none of those three, as the data is unlikely to be backed up, and you cannot assure data security. Instead, you’d find some space on a share on your archive server – or create a LUN using spare space on one of your SANs.

The same applies to email. Off-loading email from your Exchange Server to user PCs has significant risks attached to it. Instead, you should use an enterprise mail archiving solution. The product I usually recommend is Symantec Enterprise Vault, although there are many others. The main benefits? Data is still stored centrally, under the guise of your retention policies and backup process. To the end user, they can still view archived emails using a handy web interface (yes, a web interface – providing remote access to the archive).

Okay, but what about when disk space on my Exchange Server runs low or I hit the store size limit?

UPGRADE THE SERVER! Exchange 2007 and 2010 do not impose a hard limit on the mail stores, and you shouldn’t be trying to run a mail server with little disk space or database space remaining. Archiving to PST is a quick solution, but one which won’t work in the long run.

With the soon-to-be Exchange 2010 release, significant changes have been made, one of which is the addition of archiving support. Each user can be given a separate ‘archive’ mailbox; it is attached to their main mailbox, but allows for data to be archived for long term storage. The settings governing when and how mail is moved to the archive are controlled by retention policies, giving the administrator greater control over retention. Again, the archive store is available remotely via Exchange 2010′s Outlook Web App.

Use 2: On the road

For users on the road, there is no need to store their mail in a PST file. Cached Exchange Mode is available in Exchange 2003/Outlook 2003 and higher, allowing users to work offline with a cached copy of their mailbox. When they reconnect to the network, the changes are seamlessly synchronised back to the server.

Use 3: Exmerge/Export-Mailbox

This is just about the only use of PST files which I can agree to — and I’ll admit, I’ve used this approach myself. If you migrate to a new mail system or rebuild your Exchange system, sometimes you cannot avoid using exmerge (or Exchange 2007′s export-mailbox management shell cmdlet) to take handy copies of the mailboxes – which can later be re-imported to the new system. For moving mailboxes between servers, you would use the Move Mailbox wizard – but for large scale rebuilds, exmerge is sometimes your friend.

Be cautious though; Exmerge uses the ANSI PST format, so you will need to meticulously plan your export and import procedure for larger mailboxes.

Use 4: Home Users

These are the people who the PST is most applicable to. If you are connecting via Outlook to a Post Office Protocol (POP) host to download your email, that email will be stored in a PST file. The fact you don’t have an Exchange Server doesn’t change any of the points above, though; that PST is still susceptible to corruption. If mail is deleted off the server, this could lead to data loss.

For this issue, you really have two solutions. The POP3 account in Outlook can be configured to leave email on the server. This acts as a backup; if your PST file becomes corrupted, the ISP still has a copy of your messages, so they can be downloaded again. To configure, open the Tools > Account Settings dialog in Outlook. Select your POP3 account, choose Properties, press More Settings, then switch to the Advanced tab. Under the Delivery section at the bottom of the window you should check the “Leave a copy of messages on the server” checkbox. If you want a backup of all your mail, don’t enable the option to remove it from the server after a certain time period.

The disadvantage to the POP3 solution becomes apparent if you move to another computer or access your mailbox via your ISP’s webmail interface. The message state information (tracking of read/unread or whether the message has been replied to or forwarded) is not transferred back to the ISP, so all the mail you thought you had read and handled will still be marked unread on the ISP’s server.

My preferred solution, and the one I use regularly, is an Internet Message Access Protocol (IMAP) account. The IMAP protocol is another mail protocol used to access email; it stands alongside POP. However, using IMAP, you replicate a client-server topology very similar to connecting to an Exchange mailbox with Outlook in Cached Exchange Mode. With IMAP, email generally remains stored in your mailbox at the ISP until you specifically delete it. Nevertheless, you can’t get away from PST files completely; they are still there when you use an IMAP account, as Outlook uses them to make a cache of the data for working with the IMAP account in offline mode. However, as the PST isn’t the only location where your data is stored, any corruption is not going to lead to data loss.

It should be noted that both the POP solution for leaving data on the server, as well as the IMAP solution, both have drawbacks, as items in your Calendar, Contacts or Tasks folders will not be stored on the server. IMAP does not support special folders – such as the Calendar or Tasks – and these will not be replicated back with a POP account, so you will still be using a PST file to some extent. Unless you move entirely into the cloud (use web services for email, calendar and contacts) or purchase your Exchange Server, you won’t be able to easily get away from this.

Conclusion

I’ve covered a fair bit of information regarding PST files here. Hopefully, my points detailing why the use of PSTs is so impractical will now encourage you to reconsider your PST usage, archiving practices and retention policies.

With all your user mail stored safely on the Exchange Server, rather than local PCs, assistants can become delegates for their managers, looking after their mailbox; the administrator can rest assured that all data is centrally stored and backup up and you can turn off Outlook AutoArchive, relieving end users of that annoying prompt every couple of weeks.

This article was originally published at Experts Exchange.

Follow

Get every new post delivered to your Inbox.