iPhone OS4 and EAS issues

I do remember my first “real” tech job way-back-when.  Exchange 5.5 was cutting edge technology, which is dating me for sure. We had a graphics consultant come into the company for a couple of months to help re-design our website, and that required that this employee have an email address and account with our firm.  Getting them an account was no issue, as Mac systems could easily talk to an Exchange 5.5 server at that point, but once we connected the Mac to the network, it immediately took over the Exchange system. 

I don’t mean that it was easier to control Exchange via the Mac, I mean IT TOOK OVER THE @!#(%$ SERVER!

No one could get email, no one could send us email, nothing worked at all unless you were on the Mac itself.  Finally, after bringing in a Mac expert for a few hours and a ton of troubleshooting with Microsoft, we found the issue. It was a rare hiccup in the Mac networking that caused Exchange to essentially ignore anything else, and we fixed it with no future problems.

Recently, I heard of the same issue happening again, but not rare, and on the iPhone.  After the complete metal breakdown brought on by the thought of the nightmare recurring, I did some investigative work for you, my readers – and for the sake of my sanity.

As reported in Exchangepedia, the issue revolves around a bug in the iPhone OS4 software that hurls a wrench into the Client Access Services (CAS) systems of Exchange 2007 and 2010.  This isn’t an Apple-specific issue, as you could see the same problem on Google devices, but it does appear that it happens much more often with iPhone systems running OS4.  What happens is that the iPhone makes a series of requests to Exchange to perform ActiveSync.  The problem is that there is a relatively short timeout on these operations (30 seconds) and if the CAS system is busy, the iPhone will send the requests again.  And again.  And again… Eventually, the flood of requests becomes a contributing factor in the delay of the response, creating a never-ending loop.  The only way to stop it is to either stop the iPhone or the CAS system and start over, but eventually it will happen again. 

The good news is that there are ways to increase the timeout, and therefore reduce the incidence of this happening in your corporate environment.  The link above has information on how to obtain a profile update that fixes the problem in most cases.

I guess everything old *is* new again.

What’s a Rollup?

Since the news a few days ago that Microsoft has released the Exchange 2010 Update Rollup 4 for download, I figured a couple of lines on what Rollups are would be a good thing. Many are confused as to why these Rollups exist, and when to use them.

An Update Rollup (UR) is a single-installer for many different hotfixes and patches to a single product that Microsoft produces. There have been such UR’s for everything from Windows to Office over the years, and they can make life easier if used correctly. For the most part, you don’t need them for day-to-day operations anymore, but you may use them when building up new systems.

For currently-installed Exchange 2007 and up servers, running Windows Update on a regular basis will get you the critical patches, fixes and updates you need. Just make sure you’ve authorized Windows Update to download software for other software running on Windows (it’s one of your settings in Windows Update) and you’ll find yourself downloading Exchange components as well. You still need to install Service Packs as they’re available, but the individual patches can be updated when you do your regular Windows Updates. There are a couple of cases, however, where this updating process doesn’t meet your needs.

If you’re building a new Exchange 2007 or 2010 system, for example. After installation and (where applicable) Service Pack updating, there may be a large number of individual fixes and patches to be applied. As these will be installed sequentially, and will require service or server restarts in many cases, the process can be time and labor consuming. The UR can apply all patches and fixes up to the date of UR release in one shot, making things faster, easier, and with fewer opportunities for errors.

Many companies prohibit auto-updates, and you may find yourself manually applying fixes and patches for Exchange. If you keep up with this process, then you have no problems, but if you do not; you can quickly find yourself knee-deep in required updates. The UR will make life easier by bringing you up to date quickly, so you can get back to regular patching.

Note that you should still check for updates *after* you go through the UR process. This is because there may be newer patches and fixes released after the UR is built, so while it is cumulative up to the release date, it is not current to today’s date.

Keeping up to date is the best way to avoid security pitfalls and software bugs.  When you’re starting from scratch or trying to catch up, Update Rollups can provide a way to quickly get close to “up-to-date” and help you do so without as many reboots, restarts and errors.

Why would you bring up an Exchange Server offline?

The Exchange Team Blog recently posted an article on how to help speed up the time certain Exchange Server services take to start when the server isn’t connected to the Internet.  You can read the article via this link. The question I’ve been hearing after this article showed up was “Why would I bring up an Exchange Server that isn’t net connected?  Isn’t the point of Exchange to send/receive mail?”  Valid question, but I can think of a few instances where this article can really help folks.

1 – You aren’t sure what’s broken

This is a pretty common one, believe it or not.  When troubleshooting Exchange, sometimes servers can appear to be connected to the Internet, but are not.  They may also require several reboots to properly correct whatever went wrong with the network connection once you figure out what broke.  In both cases, having a way to speed up the Exchange service startup can make troubleshooting faster and more efficient.

2 – You’re testing something out

Many times, administrators will want to see how certain changes impact Exchange Servers without allowing them to receive new mail (just in case they have to revert to a previous version of the database).  This is typically done by disconnecting the server from the network, as that will ensure no mail is transferred in any direction.  If a reboot is required for the testing, shortening service start times makes life easier.

3 – Secured environments

The article specifically mentions this one.  If Exchange Server is used for internal mail routing ONLY, and never expected to send/receive anything on the public Internet, then it may not be connected to the public Internet at all.  Under these specific circumstances, there’s no reason for things like public certificate updates to happen, since the Exchange Server will never use them.  Be very careful with this one, though. You’d be amazed how many times I have found so-called “isolated” Exchange Servers that are chattering away with the outside world.

As you can see, there are reasons why you would bring an Exchange Server up without a connection to the Internet.  In those circumstances, the guidance in the article can help speed up the process of getting your Exchange services started.  Just be careful to follow all the warnings in the articles, as a wrong move could either break Exchange or create a whopping security hole in your email architecture.

Exchange Server Deployment Assistant is a great tool!

Just a quick post today, as I’ve missed most of this week and didn’t want you readers to go into withdrawal =)

Microsoft apparently agrees with me that trying to figure out what steps to take in installation of Exchange 2010 can drive you batty.  In response, they’ve created the Exchange Server Deployment Assistant (ESDA) to help you know what to do when.

The tool is web based, and simple to use.  You tell the tool if you’re planning on upgrading from a previous version of Exchange or a net-new install of 2010.  You also tell it what components of the Exchange Server 2010 system you’ll be using – Disjointed namespaces, POP/IMAP, Unified Messaging, etc.

Once you give it this info, it walks you through all the steps required to properly install and configure the services you chose.  This includes pre-requisites for the OS and Features and Roles, and the installation and basic configuration of the Exchange software itself.  A great tool for those who want an idea of what needs to be done, start to finish.

You can find the ESDA tool here. Note, you’ll need Silverlight to use the tool, which is freely available from this link.

See you next week!

“I need an Exchange Server,” - it’s not quite that simple.

A partner called me today, distraught that he couldn’t get a simple answer to his client’s question.  What was the question?  “What do I have to buy to build an Exchange system for 200 users.” The frustration stemmed from the conversations that my vendor friend that had with the client about things like server class, storage, and about a dozen other criteria he wanted to be sure of before quoting out the hardware and software necessary to get the job done.  From the research the client had done on their own, they believed it should be as simple as buying “a server” and “some disk” and doing the Exchange install.

This particular vendor knows I work for Double-Take Software, and that I am one of their Exchange SME’s, and so reached out to me to see if I could come up with an answer on the failover/availability portion of the question, since that was also going to be a requirement for this environment.  He was less than thrilled with my answer, which fell somewhere between “are you insane,’ and, “I’m not touching this with a 40 foot pole.”

Eventually I settled down, and started walking through all the things that were wrong here, and trying to find some way to get the questions simplified enough so that the client didn’t feel like they were being asked to… well… architect a complete Exchange solution for their environment. It was quite the process, let me tell you.

In order to help those who have never worked with Exchange Server before, let me spell out a few of the things you will need to know before you move forward.  For those who work with it every day, I hope you can use this as a plain English explanation of what’s involved so that you can explain it to those who may need to sign the checks, but don’t know the tech – should you ever run into that problem.

First things first. “Exchange Server” isn’t a server.  It’s a platform of software tools that all work together to provide email, collaboration services and shared data services to end users.  That means that you can’t just buy “an Exchange Server,” and in most cases it’s not one server at all, but two or more acting in concert.  To say “I need an Exchange Server for 200 people” is like asking a car dealer for “a car that can go 10 miles each day.”  Do you want a car that can hold 2 people, or 4?  Are you planning on only moving people or do you have pets?  How about cargo space, are you planning on carrying groceries for those 10 miles, or hauling bricks?  Oh, and do you want a car that can go 5 days between trips to the gas station, or do you want an SUV that’s going to suck up the whole tank during each 10 mile trip?

To beat that analogy up even further, Exchange is only the engine, not the car.  Much like other types of engines, it works better in some car chassis than others.

So, what do you plan to do for your 200 users?  Do they use a lot of email all day long, or is it just light email a few times a week?  What do they email, just regular text emails, or are they shipping multimedia presentations back and forth to each other and outside the firm? Are they all in one office, or spread out across multiple offices all over the place?  If they are spread out (or if they access mail from home, etc.) what level of security do you need to provide?  Are they doctors (HIPPA) or officers of a public company (SOX)?

Now let’s talk about some other things that may go on in your environment.  Do you need to be able to schedule conference rooms, company vehicles or other shared resources?  How about generic email boxes, like for users to request information, open support tickets or contact a salesperson or media contact?  In other words, is it 200 users that need 300 mailboxes all told, or is it 200 mailboxes?

How big were you planning on letting these mailboxes get?  Left to their own devices, users can accumulate gigabyte after gigabyte of data.  I know some sales folks who routinely have about 6-8GB of data in their email boxes.  And speaking of all that email, how long do you plan on keeping it?  Do you need to archive older mail (which you should do) or do you need to permanently delete things over a certain again (which you may need to do)?

As you can see, things are quite a lot more complicated than “get me an Exchange Server for 200 people,” and we’re not done yet.

Let’s talk Exchange Ecosystems.  That’s Microsoft’s term for all the servers and services that surround the Exchange Server in most environments.  Don’t think you need that?  You may want to think again.

Anti-Spam, Anti-Virus and other message hygiene tasks could be done on the Exchange Mailbox server, but typically for systems over about 100 users, they’re done by independent servers well before the email reaches the mailbox.  That means either creating servers dedicated to those jobs, or – more likely at this size – leasing services from a 3rd-Party provider of message hygiene solutions.  If so, do you want to host an appliance at your site, or outsource everything?

Speaking of outsourcing, 200 users is still well within the range of Exchange Hosted Services or other forms of Exchange Server Hosting.  Then you can just outsource everything and tell the vendor what features you want.  Can you do that in your industry and with the regulations/company policies you’ve got in place?

People rarely stand still for long.  I’m writing this blog posting on a train heading to Boston, but I have full access to my entire Exchange mailbox and other corporate resources through Outlook Web Access, Outlook Anywhere via my air card, and of course my Blackberry device.  Do your 200 users all need to be able to have that kind of access? If not, how many do and how many do not?  Do you need to configure Outlook Anywhere (the components of Exchange that enable many mobile devices like Windows Mobile and iPhones)?  Do your mobile folks like Blackberries instead?  If so, do you want to host your own Blackberry Enterprise Server, or outsource that too?

While we’re on the subject of people talking to each other, do your users need to share more than email?  Do they routinely cooperate on documents, lists, wikis and other things too?

At this point, you may be ready to throw your hands up, throw the idea of creating an Exchange Server out the window, and go home.  Don’t give up yet, because here’s where we tie it all together:

Exchange Server 2010 is the currently shipping version of the Exchange Server Messaging and Communications Platform.  It contains the ability to set up mailboxes, message hygiene and routing for email, communication with mobile devices and connections to other tools.  It’s available in two “flavors” – Standard and Enterprise.  With 200 users, you’re almost definitely looking at the Enterprise version, which is good, because it can help a lot with the high availability questions.  Most clients will also need additional availability solutions (see disclaimer below, I’m biased) and backup solutions as well.

Also, you’ll need Client Access Licenses for each user/mailbox.  There are two types, Standard and Enterprise.  Enterprise CAL’s allow you to do things like grant mobile access and get archiving and cross-mailbox search, so you will most likely need those for at least some of your users.

Next, what kind of hardware will you be needed?  Well, if the 200 users don’t do a lot of email work, you can get away with a lower-class machine than most.  You may even be able to squeeze everything on to one server, though putting the front-end systems (called Hub/Transport and Client Access Services) on their own server isn’t a bad idea.  You’re right on the edge of needing to split everything out anyway, and if you’re planning on growing (which hopefully you will) then you’re going to need to do it sooner rather than later.

As for what those servers will look like, there’s a lot of debate on that topic, so for this article I’ll use the official specs from Microsoft.  You can find them (and a lot more info) on the Microsoft TechNet site on Exchange Performance and Sizing.

Your front-end server should have between 4 and 12 cores, which you can get by using 1 to 3 quad-core processors, which are the standard these days.  The Mailbox server needs more horsepower, so you’re looking for from 4 to 24 cores there.  RAM-wise, front-end servers should be getting about 4GB-8GB each.  At this level you’ll probably only have one front-end server though.  Mailbox servers need 4GB to start, and then need 3MB/mailbox if your users are light email users.  If most of your users are heave emailers, with lots of attachments, huge contact lists and tons of calendar appointments, you should be looking more toward 30MB per user mailbox.

Disk space is another concern.  Microsoft has made Exchange 2010 much more efficient with disk than its predecessors, and so you can use a lot of different types of disk options.  You will need to be able to hold all the information not being archived or deleted, so think in terms of 200% of what you’re allowing your users.  So if each user can store up to 3GB of data in their mailbox, you should be allocating 1.2TB (3GB x 200 users x2) of storage space for them.  This will allow you to allocate space for Exchange’s transaction logs (internal log files used to track what Exchange is writing to the databases), the databases themselves, and the necessary queuing systems that shuttle mail back and forth, with a little room to grow.  These days you can get that with just internal disk, but many clients choose to go with external arrays so they can scale over time.  Definitely check the TechNet website for recommendations on what RAID to use and other disk settings; as this is just how much disk you need, not how you should create or allocate it.

Exchange 2010 also comes with native archiving and compliance search features built in.  This will, of course, require more hardware, so have a look at the overview of these tools on the TechNet site and plan accordingly.  Keep in mind that if you use native or 3rd-Party backup/availability tools, you’ll also need another server and appropriate disk space to hold the backup copies of the data.

External to the Exchange Server itself, but just as important, are the Ecosystem servers.  SharePoint Server allows your teams to share documents, calendars and projects easier than the native tools in Exchange Server could alone.  SharePoint is a whole other server platform, but one that you should look into if your users tend to share stuff on a daily basis.

Blackberry and Good Technologies are two common tools that work side-by-side with the native Outlook Anywhere (formerly known as ActiveSync) systems in Exchange.  If you have Enterprise CAL’s, your users can access email via Outlook, Outlook Web Access, or a host of mobile devices like iPhones just by using Exchange Server.  If you want to add extra security and sync features, then you use Good.  If you want your users to have access to the popular Blackberry mobile devices – and centrally control and manage them, then you’ll need Blackberry Enterprise Server (BES).  Good can often by installed to the Exchange Mailbox Server, but it’s a better idea to give it its own server so it doesn’t bog down the mailboxes.  BES can either be provisioned on its own server at your site, or you can lease space on a hosted BES service provider’s server.  If you host your own, then of course you will need a server to put it on.

Summing up, we’ve gone from “I need an Exchange Server for 200 people,” to, “I need several servers of different sizes to host all the components of Exchange Server for my organization.”  If you have never touched Exchange Server before, this can be bewildering, frustrating and expensive – especailly seeing as you’ll probably goof up at least once (we all do).  The good news is that there are two options if you just can’t wrap your brain around all of this.

One is to get help.  There are a huge number of service providers who can assist you in planning, procuring and implementing all these moving parts.  Many can also train your team to maintain what they built, and to build out new stuff when needed.  If you plan on hosting everything yourself, this is the much better course of action to take, as going it alone quickly gets more expensive as you fix mix-ups than the consulting costs would have been.

Alternately, you can talk to Microsoft and their partners about having someone else host and administer your Exchange solution.  Hosted Exchange Services is the product offered directly by Microsoft, and many partners also host Exchange services on their own.  Take a look an article or two before this one in this blog for some details on that.  Up to 500 users/mailboxes, it is quite suitable to go the hosting route, and even up to 1000 users it can make a lot of sense.  It’s still Exchange Server, you still get Outlook, Outlook Web Access and Outlook Anywhere – and you may be able to get Good and BES too.  You’re trading management and hardware costs for a monthly cost per user and/or per amount of storage space they use.

So, what does it boil down to?  The short answer is that there is no valid short answer here.  You need to take a look at your users and your datacenter facility.  You need to know what they want to do with their messaging systems before you can even begin to install Exchange Server components.  Exchange Server is no longer something you can just buy “off the rack” and toss into your environment.  Plan, implement and manage it correctly, or it will be nothing but a nightmare until you eventually do the planning and rebuild it right – which always costs a lot more.

Confusion over “2003 AD” and “2008 AD” with Exchange Installs.

One of my colleagues ran into this one last week, so I thought I’d share the issue here, and detail the fix.  When you go to install various versions of Exchange Server (2003 and up) and/or try to activate certain Exchange functionality, you may find that your Active Directory (AD) domains are not at the correct functional level, even though they appear to be.  Here’s a case in point:

I checked, and my domain is at a 2003 domain level, but Exchange Server 2010 says that it isn’t…

At first glance, this is an infuriating problem, because my colleague definitely confirmed that the Domain Functional Level was “2003” and the installer just wouldn’t work. The issue is a matter of one word versus another – specifically “Mixed” versus “Native.”

Mixed mode domains are designed to allow earlier versions of Windows AD Servers to operate properly in an environment that is being upgraded to a new AD platform.  Today, it is not uncommon to see 2003, 2008 and 2008 R2 Domain Controllers (DC’s) in a single environment, and the Mixed mode of each of those AD versions can allow for interoperability.  Exchange Server 2010, however, cannot operate if there are components of AD/Domain Services from Server 2000 or NT.  As such, it requires that only Server 2003 or higher AD controllers exist.  This means that you must be in 2003 Native mode (or higher) to install Exchange Server 2010.

Native mode ensures that no DC’s of any version prior to the functional level can communicate with AD in this domain.  This allows software packages like Exchange Server to not have to worry about passing commands that might be incompatible with earlier versions of AD.  Additionally, some features of Exchange Server 2010 go one step further and require either 2008 Native mode or 2008 R2 Native mode to function properly, so you may be on 2003 Native and still get errors if you are attempting to enable those services.

If you get the error during the pre-flight check on the installer (or later when adding features), make sure that your AD systems are in the appropriate Native mode, instead of Mixed, and you should be just fine. Note: you will often see these modes referred to as “Legacy” and “2008 Only” or similar language.  Legacy, as the name implies, allows for earlier AD controllers to communicate.  2008 Only or 2008 R2 Only limit the DC’s to those levels and higher.

Sometimes, when it comes to Exchange Server, one word can really make all the difference.

Offline Address Book Generation/Update

The OAB is used for Cached/Offline mode clients to perform lookups of contacts and other information. It is periodically updated from the Exchange Server to Outlook clients. A complete overview of how the OAB works in various versions of Exchange can be found on Microsoft TechNet by searching the sections for your specific version of Exchange.

In earlier versions of Exchange Server, a Public Folder was used to house the OAB data and distribute it. In 2007 and 2010, a web-based distribution system was put in place, with the ability to also maintain a Public Folder version in the event you have legacy Outlook (2003 SP1 or earlier) clients. While distribution of the OAB to any Outlook client is fairly automatic, the generation of the OAB for the first time may not fit into your time tables.

Usually, the OAB will update as part of the Online Maintenance Routines that occur by default every day from 1am to 3am server local time. This means that the OAB will not be generated at all until that first maintenance window, and will not be updated with new users until the first maintenance window after they are added to AD. There are several reasons why this may not work for you, but some common ones are:

- You’ve added a VIP to the AD system and management doesn’t want to wait 24 hours for the OAB to update.

- You have created a test system, and either don’t want to leave the system running overnight, or need to perform testing within the first 24 hours of the build.

- You add a large number of users to AD, and want to propagate the information to Outlook clients as quickly as possible.

In these, and other cases, you could force the Online Maintenance to occur, but that would take a significant amount of time, especially if all you want to do is update the OAB. In a production environment, performing maintenance routines during peak hours of operations can also have an impact on user experience, and so should be avoided.

To perform an immediate update of the just the OAB in Exchange Server 2007 or 2010, you can open a PowerShell command window and execute the following:

Update-OfflineAddressBook –id “Name of OAB” –verbose

Where “Name of OAB” is the name of the Offline Address Book you wish to update. Be sure to enclose it in quotes, especially if the name contains spaces. The default OAB for a new installation of Exchange is – oddly enough – “Default Offline Address Book” and you can use that name to perform the initial update on a brand new server.

If you maintain more than one OAB, or if you changed the default name, you must run the command for each OAB in your organization, replacing the name with the appropriate string each time.

The next time Outlook clients look for OAB information, they will see that the OAB has been updated, and download the appropriate changes to their local OAB copy.

Got an Exchange-related question that Mike can try to get you an answer for? Follow Mike Talon on Twitter (@TalonNYC) and send an @ mention with your question.

What the {Censored} Do I Install for Exchange 2010??!!

This is a complaint I have heard over and over again from clients going to install Exchange 2010l and even earlier versions.  The level of profanity depends a lot on the individual, but I have heard some rather prim and proper folks resort to very short words when it comes to Exchange pre-requisites. Come to think of it, they've resorted to some long words as well, but none fit for publication in family-friendly venues.

Exchange prerequisites have typically been confusing and difficult to master.  Starting with Exchange 2000 and 2003, the pre-flight checks built into the setup protocols became intelligent enough to figure out what was missing for the most part.  However, the installer didn’t tell you what those things were unless you started playing with the install options and suddenly got a popup which detailed what wasn’t there.  Exchange 2007 and now 2010 both have extensive pre-flight checks that occur before you do any form of installation, just after you tell the installer which components you’d like to put on the box.  They check for everything from your .NET versioning to Active Directory connectivity, but once they tell you all the different things that are not present, how do you figure out what to install in order to make those things present?

Thankfully, Microsoft has had TechNet pages that detail prerequisites for Exchange installations, starting back in Exchange 2000.  Up until 2007, it was up to you to install each of the components listed, but with the advent of newer server management tools in Server 2008, the process can be automated.

For example, to pre-stage Server 2008 R2 for Exchange 2010, you can invoke a series of PowerShell commands to set up nearly all the prerequisites in one shot.  First run:

Import-Module ServerManager

inside a PowerShell window in order to load the correct command modules into the session.  Then, use the correct sequence of commands in the same PowerShell window to load the prerequisites for the roles you need to run on this particular server.  For example, if you wanted to run Hub/Transport, Client Access Services and Mailbox Services; you would execute the following block of commands:

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy –Restart

The specific commands (and the tool to call them) will change based on three things:

1. The version of Exchange (2007, 2010, etc)
2. The version of Windows (2003, 2008, 2008 R2)
3. The Roles you intend to install (Hub/Transport, Client Access, Mailbox, Unified Messaging, etc.)

Some things, like installing the 2007 Office System Converter Filter Pack; still have to be done manually, but most of the basic pre-installations can easily be automated using these combinations of command window and PowerShell scripts.

Microsoft has put up all the commands and processes for all the Server OS’s that Exchange 2010 can run on in this TechNet article.  Similar articles exist for previous versions of Exchange too, so you can get your prerequisites onto the server before you even start the Exchange 2010 installation executable.

Outlook Mail stuck? It may not be your profile.

During a recent Exchange 2010 training, our instructor went through a couple of things that could be causing mail to not leave an Outlook or OWA client during normal operations.  When I did a few searches on this topic, I was alarmed to see that many people suggest that the problem is the Outlook offline storage file or PST.  While that does sometimes cause these issues (especially if you’re on Exchange 2003 or earlier), there are a couple of quick checks you should make against the server first.

On Exchange 2007 and 2010, if mail is getting stuck in users’ Outboxes on various clients, check two things:

1 – Is there less than 4GB of disk space available on any volume on the servers that contains Exchange data and/or queues? If there is less than 4GB, Backpressure protocols kick in, and Transport Services won’t move mail anywhere, leaving new messages stuck in users’ Outboxes. This is fixed by freeing up drive space or moving the database and/or queues to another volume with more room.

2 – If the disk space is ok, check to see if the Transport Services (which vary depending on your Exchange version) are running.  Any service that isn’t started can cause mail routing to fail, and messages to stay on the client software.  Obviously, to fix this you either need to get the services up or bring another Hub/Transport system online to handle mail flow.

Additionally, if you are using Exchange 2010, mail may get stuck in the Drafts folder.  That is to say, it leaves the Outbox and immediately appears in the Drafts folder in Outlook.  If you see this behavior, check to ensure that the Mail Submission service is running on your CAS server.  If it isn’t, mail can’t be properly picked up from the Outlook client, and the resulting error shoves the email into the Drafts folder.

Granted, if these issues are not the cause of your issue, or if it only seems to be happening to one user, then rebuilding the OST or PST might be in order.  However before you disrupt clients day-to-day activities, a quick check of the server might uncover a correctable error that can be quickly contained.  In the case of lack of disk space, it can even expose a growing problem that must be dealt with in the near future to avoid much more wide-spread downtime.

Two for tea, and tea for 2007?

Those following my twitter feed (http://www.twitter.com/talonnyc) already know I’m in an Exchange 2010 training this week at New Horizons here in NYC.  During the class, someone had asked if you could run both the Exchange 2007 and 2010 admin tools on the same system, and our trainer (though extremely well versed on just about any other topic we threw at him) wasn’t sure on that one.  Luckily, the twitterverse came to the rescue and Henrik Walther the Editor of MSExchange.org sent over an article that went through the details on this, and many other topics on Exchange 2010 management.  The article found here is definitely worth the read, but since it covers several other topics, here’s the skinny on multiple client tools installs:

2003 Tools: Cannot be installed on the same system as 2007 or 2010.

2007: x86 tools can’t be installed with the 2010 tools, but the 64-bit versions can co-exist

2010: Only available in 64-bit versions, and can co-exist with the x64 versions of the 2007 tools

To use both the 2007 and 2010 tools, install all pre-requisites for the 2010 versions.  This includes PowerShell 2 and the .NET 3.5 (go with 3.5.1) Framework package, along with others.  Consult the install guides at MSExchange.org for more in-depth details on what you need to have on your workstation ahead of time.  The Exchange 2007 tools are compatible with these upgraded pre-requisites, and so can either be left in place (if already installed) or installed first.  Then install your Exchange 2010 tools and you are on your way.

Always remember to use the Exchange 2010 tools whenever possible.  Certain configuration specific to Exchange 2010 (Like Moderation rules) will be ignored by the earlier tool kit, even though it will let you do many operations with either version.  This could lead to you accidentally ignoring a vital configuration or management step along the way.

Thanks to Mr.. Walther for the excellent information!

Public Folders continue to be whittled away

With each new release of Exchange Server, Microsoft de-emphasizes available Public Folder functionality and restricts Public Folders from participating in the newer technologies of the current release. Of course, they also announce that they make no promises as to Public Folders even being included in the next release down the line.  Exchange Server 2010 is no exception to these rules, and while Public Folder technologies are still in the release, they are restricted and downplayed overall.

With the RTM version of Exchange 2007, you needed to use Outlook or other tools to manage folders, but the backlash from end-users was so fierce that Microsoft put the tools back into Exchange with the SP1 release. Still stinging from that set of events, the Exchange Team seems to have built at least basic Public Folder functions into the shipping release of 2010, but with some limits.  A few of these were limited in 2007, some are new.

As with 2007, Outlook and Outlook Web Access are about the only remaining methods to connect to Public Folder trees.  Gone are the days of NNTP and IMAP access to folders, and apparently gone to stay.  Since most users who need Public Folder access use Outlook anyway, this wasn’t a huge issue, but it did hamper 3rd-Party Public Folder integration unless the vendor was - or is - using MAPI connectivity.

The new clustering solution set that was introduced in Exchange 2010 (Database Availability Groups, or DAG) doesn’t support Public Folder databases either.  You can, however, host Public Folder databases on MBX servers that are using DAG for their Mailbox Stores.  You simply have to use some other replication system to protect the data (either Public Folder Replication or a 3rd-Party system – see disclaimer at the end of this blog).  More info on this can be found on TechNet.

So, while Public Folders are still not dead yet, they are systematically becoming a very difficult feature-set to continue using.  Microsoft has been actively encouraging Exchange users to leverage the functionality of a SharePoint Server to replace what was once stored in Public Folders, and for the most part you can do much more with SharePoint overall.  There are several 3rd-Party tools available to move your Public Folders to SharePoint, and once there you have a great deal more control over content, accessibility and general functionality.

If your organization uses a great deal of Public Folders, and you intend to move to Exchange 2010, consider migration of the folder information and functions to SharePoint.  Doing so as part of an overall migration strategy is a lot better than trying to rush the job after you find out that Public Folder functions in Exchange 2010 may no longer do what you need.

Don’t uninstall to fix Exchange!

Exchange Server does, occasionally, act oddly.  Alright, it can do that a lot, but hopefully you won’t run into the phenomenon.  If you should see strange behavior from your Exchange Server, the first thing to remember is that it is not a truly stand-alone application, and can’t be treated as such.  When problems happen with many software packages, the default fix-it is to uninstall the applications, reboot and reinstall.  While that may work with many apps on the Windows Server platform, doing that for Exchange Server will lead to rather disastrous results.

When Exchange Server installs, one of the first things it does is start building structures in Active Directory.  If you have no Exchange Servers at all, this includes extending the Schema and creating an Organization for Exchange and the related security constructs in both the Forest Root domain and the domain you’re installing into.  The thing many folks don’t realize until it is too late, is that much of this mucking about in Active Directory is undone when you uninstall an Exchange Server, which could be a problem if you plan on just fixing something and moving on.

When you uninstall Exchange Server, the uninstallation protocol will remove all objects in AD that were assigned to that server, which could lead to unexpected end results for users, Public Folders and other objects that don’t exist elsewhere in your organization.  This means that an attempt to uninstall to fix a somewhat minor issue could result in an absolute disaster for your Exchange environment overall that cannot be fixed by simply failing over.  The Organization and Forest Root updates will remain, but most of what you did in terms of configuration for the specific Exchange Server will be wiped out.

So, what to do in order to avoid this?  First, hit http://technet.microsoft.com and http://support.doubletake.com to see if there are articles on how to fix the problem you’re seeing.  These documents generally detail much easier fixes for common Exchange problems, and not-so-common ones as well.  Correcting the issues with Exchange still in place is the best route to take when it’s available.

If you do have to reinstall Exchange, your best bet is to shut down the malfunctioning server, build a new one with the same name, and use the disasterrecovery or recoverCMS switches with the Exchange Server installer tools.  This will transfer the settings over to the new machine, instead of removing everything permanently from AD.  Nearly all configuration for Exchange is stored in AD, so using these switches during the installation will allow you to get back up and running quickly, ready to restore the mailbox and folder data from an independent backup.  More information on these switches, the exact syntax for each version of Exchange Server and guidelines for use can be found in various places. http://support.microsoft.com, http://www.msexchange.org and http://technet.microsoft.com are three great resources.

As with most other topics, Exchange acts differently from most other applications when it comes to reinstallation. Always check the support sites before you take any drastic measures, and remember that Exchange is a totally AD-integrated application, so you’re never working on “just the Exchange Server itself.”

Take Care With Exchange 2010 Throttling Policies

Many of my clients are currently evaluating Exchange 2010 for their production environments. While they probably won’t be implementing for a little time yet (average target dates are in Q4 for most clients I talk to), they are beginning to see different switches and settings that need to be tweaked from their defaults.  One of those settings is the native Throttling Policies that Exchange 2010 puts into effect to limit how much of various Exchange resources other applications are permitted to use.

Brian Desmond wrote a great article (you can read it here) that goes into detail about one potential problem that these limits impose.  Since the Throttling Policies are designed to stop individual client applications (among other things) from using up all the resources of an Exchange Server, they can impact 3rd-Party tools just as much as POP, IMAP and other mail client software.  In Brian’s article, he brings up the difficulties that Blackberry Enterprise Server (BES) runs into with the default policies, as they would normally hamstring BES’s ability to use a single account to ferry messages back and forth between Blackberry devices and the Exchange Server itself. 

In this case, what applies to the BES server can also impact other 3rd-Party applications that need to access an Exchange database via a client connection.  For example, archiving systems not using the new native tools may be working via a Journaling Mailbox or other single-account connection system. This means that the policies, as set up by default, would severely hamper the ability of the archiving system to get the data from the Exchange Server and into the archive solution.  Using the native archiving and compliance tools will help fix this, but many clients have invested a huge amount of time and money in setting up existing solutions. This means they face the choice between paying and implementing for an upgrade to the 3rd-Party system, versus completely re-engineering their archiving and compliance systems to switch to the native tools. 

Also, consider periodic mass-connectivity.  Anti-virus and other scanning tools may periodically connect to the exchange system using client connectivity, as would some 3-rd Party search and indexing systems.  Both of these will most likely not be hit by the policy limits, but could be if they do a mass-crawl. Careful evaluation of all systems that use client connections is necessary to eliminate any issues before they start generating client complaints.

Luckily, it is not difficult to change the Throttling Polices in Exchange 2010.  Brian’s article offers a great explanation of it, and of course Microsoft TechNET has a full set of details.  Once you determine which applications may need extended client access to the Exchange Server, you can set up custom policies for those applications and the accounts they use.

Hyper-V Me (Yes, Even for Exchange)

Due to the release of Hyper-V R2, there has been a lot of buzz about using Microsoft’s Virtualization Platform to create virtual machines for everything in the datacenter from file servers to high-capacity databases.  There are quite a few systems that are clearly ok to use virtualization with, but Exchange Server has always been one of those platforms where virtual tech has been a questionable course.  Not the least of the reasons for this is that folks have been confused on if MSFT supports running Exchange in production on a virtual platform.  So, I’ll spell out the current support stance as found on official MSFT sites only.  Note:  There are many blog postings that point one way or the other, so I have hunted down official MSFT sites to quote here (i.e. TechNET, MSDN, etc).  While many blogs can be trusted (like the official Exchange Team Blog at http://msexchangeteam.com – and http://www.BeingExchanged.com of course), many of my readers have corporate policies about needing to see the documentation from a MSFT site directly; and so here it is:

Exchange 2000 and earlier:

Not supported for production environments.  See the end of the TechNET article found here: Link to TechNET

Exchange 2003:

Supported in production.  Warnings are given that you must use Virtual Server (2005 R2 or higher) and that there are some performance limitation to be considered. Link to TechNET

Exchange 2007

Supported for production environments on Hyper-V, but with some limitations. You must be running Server 2008 as the Guest OS, and you have to be running Exchange 2007 SP1. Unified Messaging may not be run on a Hyper-V Guest.  You cannot use both SCR and/or CCR and Hyper-V clustering at the same time. Finally, the virtual machine itself must meet all the hardware requirements (processors, RAM, etc) for Exchange 2007 Sp1. Link to TechNET

Exchange 2010:

Supported for production environments on Hyper-V, with some restrictions:  You must be running Server 2008 SP2 or R2 as the Guest OS, and Unified Communications Roles are not supported at all.  As with 2007, the virtual machine you install Exchange into must meet all the hardware requirements for Exchange 2010. You will also need to choose between DAG availability or Hyper-V failover solutions, you cannot run both at once. Link to TechNET (see section on Hardware Virtualization)

Common notes:

In all supported versions, certain functions of the virtualization systems are not supported with Exchange Server.  Specifically, dynamically expanding virtual disks are not allowed, you have to use pre-configured fixed-sized VHD’s for Exchange Server virtual machines. Likewise, you cannot leverage differencing or VSS snapshot disks if you’re running Exchange Server.

There are several rules about virtual hardware that you must follow as well, so read the related TechNET articles for guidance on things like disk types (SCSI, IDE, etc) and the like.

Hyper-V technology is bringing new opportunities to the virtualization technologies platform in the modern datacenter.  By clarifying what is and is not supported in a virtual environment, Microsoft has begun the process of allowing customers to safely start using virtualization for the Exchange Server platform.  Many users will still choose physical hardware for Exchange (either because they cannot meet one or more of the requirements, or just due to having hardware already provisioned), but these rules help clarify that options for virtualization exist and are supported.

Going cheap still has limits

Over the Thanksgiving holiday here in the US, I finally got a chance to catch up on a lot of the information on Database Availability Groups (DAG) and other neat new features in Exchange 2010.  I’ll get back to talking about earlier versions shortly, but one trend that got me thinking was that smaller organizations will be looking to use Ex2010 to get failover capability without clustering technologies and – therefore – at a lower cost.  The problem is that while you can implement DAG much less expensively than a traditional or CCR cluster, there are some severe limits you need to be aware of. 

Note: I will be attempting to keep everything very neutral in this article, but do keep in mind that I work for a High Availability/ Disaster Recovery solution provider (see notice below).

First, to spell out the Standard versus Enterprise versioning debate.  Yes, you can get DAG capabilities in the Standard version of Exchange 2010.  This means that you can create a DAG without the need for shelling out the extra cash for the Enterprise version of the Exchange Server software itself.  However, since DAG requires some of the components from Microsoft Failover Clustering, if you want to use DAG you must be on Server 2008 RTM or R2 Enterprise Edition.  So, in short, Exchange Standard is a yes, Windows Standard is a big no.

Also, keep in mind that each Exchange 2010 Server Standard may have no more than 5 databases on it.  There seems to be a good deal of confusion around that, but as has been quoted in Jim McBee's blog and other places, that doesn’t mean each Standard server can host 5 live databases.  It means that the total of both live and passive copies of databases housed on that server many not be more than 5.  So, if you want 1 live database on each of 4 servers, you can get away with Exchange 2010 Standard.  However, if you have 3 live databases on 2 servers, the Standard version is not enough to allow you to perform DAG on all databases, as that would make 3 live and 3 passive on each box, for a total of 6 per server.

One thing that is not limited is your ability to use any Client Access License (CAL) on any Exchange Server version you’d like.  Enterprise CAL’s run just fine on Exchange Standard, and vice-versa.  This means that end-users running on Standard can get nifty features without requiring you to upgrade to Exchange Enterprise.

So, smaller organizations may very well be able to use the Standard version of Exchange 2010 (but not Windows) in order to get DAG functionality for their databases and other higher-end feature sets.  Just keep in mind that there are still limitations on the Standard version, and avoid hitting those limits if you’re staying on Standard.

Look before you leap

There’s a great deal of talk these days about migrating directly to Exchange 2010 instead of jumping first to the 2007 version of the platform.  The arguments for and against this got more complicated when Microsoft did a reversal for support and announced that 2007 would be able to run (at some future point) on Server 2008 R2.  This effectively extended the support cycle of 2007, which means that a slightly older, and more thoroughly tested and widely installed, version is a legitimate option going forward.  That being said, many clients are opting to just go to Exchange 2010 from whatever they’re on now, skipping 2007 if it isn’t already in place.

I’m going to avoid discussing the pros and cons of going to Exchange 2010 directly in this particular post (that’s fodder for quite a few additional posts though).  Let’s just say that you’re jumping from an earlier version directly to 2010 and go on from there.  While most of the process isn’t too bad overall, there are a couple of sticking points that you’ll need to have sorted out before you make the move.  In smaller organizations, these are pretty easy issues to take care of, but on large-scale roll-outs, they can be a problem.

First, make sure your domains are at least at Server 2003 native functional domain levels.  Most of you are already there, but just in case you had a few NT servers hanging around, be ready for this one.  As long as all your servers are 2003 and up, making this change doesn’t have a lot of impact on your domain.  You can find out about the impact of raising Domain Functional Levels in this TechNET article.  So, what if you DO still have Exchange 2000/Windows 2000 servers in your environment?  You need to upgrade to Exchange 2007 as an interim step to 2010.  Since the Exchange 2000 life-cycle is definitely over (and has been for a while), Microsoft offers no method of co-existence between Exchange 2000 and Exchange 2010 – migration or otherwise.

Once your domain is prepped to 2003 or 2008 native mode, you then must plan to keep your old Exchange infrastructure long enough for the migration to occur.  That’s because the Mailbox systems for one version of Exchange can’t talk to any other in most cases.  So a 2003 Mailbox Server can’t talk directly to a 2010 Mailbox Server without some assistance.That assistance is in the form of Bridgehead servers (2003) or Hub/Transport and Client Access Servers (2007). You will need to have at least one of each for each Site you have set up in Exchange/AD.  One note, this has nothing to do with the migration itself, this is all about the period of co-existence you’ll need to go through until everyone is on the 2010 architecture.

After you have upgraded your Domain Functional Level and set up your front-end server systems, you can begin the process of installing the first of your Exchange 2010 server systems.  Start with the Hub/Transport and Client Access roles (unless you are installing them on the Mailbox Role server itself) to allow for message routing to get set up.  This lets mail flow between the 2010 and legacy front-end servers, so when you start moving mailboxes, you don’t lose mail connectivity.

Finally, once you’re sure mail is flowing correctly and that no one is about to get lost in the shuffle, take one more backup of the legacy systems (just to be safe) and start your migration.

You can find a guide to preparing for and deploying Exchange 2010 at this TechNET site.  Along with other blogs and Microsoft sites, this should be required reading before you even download the software and play with it in a lab.  With a migration that includes a period of co-existence with earlier versions of Exchange; careful, proper planning is not a nice-to-have thing.  It is a solid requirement that must not be overlooked or under-appreciated.

Something Old, Something New

As many of you know, Exchange Server 2010 Released To Manufacturing (RTM) today, with TechNET and MSDN releases to follow later this week.  There are a ton of new features, like Database Availability Groups and Archiving and compliance put in place in this version, so it’s a big step for Microsoft.  As you might expect, I’ll be writing quite a few articles on the new features as Exchange 2010 rolls out.

In the meantime, a recent 180 degree turn by Microsoft on support for Exchange 2007 has extended the theoretical useful lifetime of that platform by quite a bit.  It may not be time to start writing off Exchange 2007 just yet =)

As reported by Mary-Jo Foley in this ZDNet Blog post, MSFT has announced that they will continue to support Exchange 2007 into the Server 2008 R2 platform.  Prior to this point, official support for Exchange 2007 would end on the Server 2008 RTM platform, limiting the lifespan of the 2007 product to the 2008 RTM server. That wasn’t going to be tomorrow, or anything like that, but it certainly would be a shorter time-span than if Exchange 2007 got R2 support. 

Yielding to immense pressure from the end-user community, MSFT did acknowledge that not everyone was ready to upgrade to Exchange 2010.  There were no details on exactly when an update for Ex2007 would be available for R2, but suspicions are that it will be done via either a Roll Up or possibly even a new Service Pack early in calendar 2010.  Traditionally, this type of compatibility update had been done as part of a Service Pack, so my bet is riding on that idea.

Either way, the news that Exchange 2007 will live on to Server 2008 R2 is welcome.  This allows organizations who are in the middle of roll outs to not worry about if their servers are installed with Server 2008 RTM or R2, and will allow those migrations to complete on the 2007 platform.  This, in turn, allows upgrades to 2010 to occur without being rushed due to OS incompatibility issues.  There is something to be said for the fact that this decision will slow adoption of Exchange 2010 overall, but it will mean better, more structured roll-outs over time.  Safer, stronger and better planned upgrades are never a bad thing.

Can I get a Witness?

Continuous Cluster Replication in Exchange 2007 allows for two nodes of a Distributed Failover Cluster (DFC) for Exchange to be held in different physical locations and different physical network segments.  This is a good thing to leverage if you’re not concerned with local High Availability, but can lead to some interesting issues if something goes wrong.  The two nodes will use their quorum resources to find out which server should be in control of the cluster (and therefore assign resources accordingly) – but that doesn’t help if the nodes cannot see each other due to network failure.

One of two conditions would happen if you ran into this situation as described this far.  You could run into split brain, where both nodes thing they’re in charge and bring up Exchange resources.  This can take hours or even days of manual work to fix, and therefore Microsoft has taken steps to prohibit it.  If either node can’t figure out who’s supposed to be in charge, both go offline to prohibit split brain at all costs.

The second potential situation is the opposite, that neither node can figure out who is in control and both therefore shut down.  While this doesn’t put your data in danger, it does effectively shut off your Exchange system, stopping all messaging flow.  Neither situation is good, but by default, if arbitration is not possible via either quorum or other means, this safer situation occurs.  Luckily, there are “other means,” specifically the File Share Witness (FSW).

FSW is a file share (as its name implies) that both nodes can see under normal circumstances.  It must be placed on a server that isn’t part of the cluster.  Usually, you find it on a file server within the environment, but be aware that it will need to be at least Windows Server 2003 SP1 or better.  The FSW should also be placed either locally to the preferred node (the one you want to “win” in the event  of arbitration) or in an independent location that can be seen by both networks where CCR nodes reside.

In a CCR cluster, there are only two nodes, so right off the bat, if an arbitration event occurs, neither node could gain a majority and take over if there was some communication failure or other emergency.  The FSW acts as a third resource that can be polled to find out who is in control. Both nodes will attempt to take ownership of the FSW, but due to the physical placement of the Witness Server, only one will successfully do so.  That node stays online as owner of the cluster, the other node prohibits resources from going live until the emergency has been resolved.  As you can see, placement of the FSW becomes a critical component to the overall success of this arbitration system.

If you have only two physical locations, your best bet is to place the FSW on a server in the secondary site.  This allows the cluster to properly arbitrate to the remote site if the production site goes offline.  If you have more than two locations, then you can place the FSW on a server at a third location, just make sure connectivity to that site is stable and constant to and from both CCR servers.  If that link is unstable to one or more sites, you can create accidental arbitration events when they’re not really needed.  The benefit to putting the FSW at a 3rd site is that you can survive a link outage at either CCR node location without having to manually force one node or the other to take control (called a Force Quorum Operation). 

Here’s an example of what I mean.  If you have only two sites, and place the FSW at Site 2, a network link failure at Site 1 would force arbitration to Site 2 since the CCR node at Site 1 would not be able to communicate with either the node at Site 2 or the FSW hosted there.  In this scenario, there may be no value to failing over to Site 2, but you would automatically fail over anyway.  If, however, the FSW is hosted at a 3rd site, and both sites can see it, then a network fault between Site 1 and Site 2 would not flip everything to Site 2. Since Site 1 is the preferred owner, and can maintain control of the FSW, it will stay in control of the cluster.

You can find out a lot more about configuring FSW for Exchange 2007 via this TechNET article. The use of FSW technology is mandatory for CCR, and will continue to be a good idea for Exchange 2010 and Database Availability Groups as well.  Learning how this technology works today will allow you to create redundant solutions that last through your future Exchange solution sets.

Power(Shell)full Stuff

Windows PowerShell was introduced a few years back, but is still trying to find its way in the big, bright world of Windows even today.  This command-line interface allows users of all versions of Windows from XP SP2 on up to navigate through day-to-day operations without walking through layers of GUI interaction to get there.  While somewhat slow to take off in the mainstream Windows admin world, for Exchange Server (2007 and up) it has become an essential part of the Exchange Engineer’s toolkit.

With Exchange 2007, Microsoft removed a great deal of the control functionality from the Exchange Management Console (EMC) in favor of the extensions that Exchange makes to PowerShell, creating the Exchange Management Shell (EMS).  At first blush, this seems to be taking one giant leap backwards in terms of command and control on a Windows Server (DOS, anyone?) but once you dive a little deeper, there are a lot of advantages to be found.

Let’s start with speed.  EMC is slow, very slow.  Waiting for each command to finish loading up in the GUI just to figure out the piece of information you need is painful, to say the least.  The main reason for this is that the EMC doesn’t really do anything itself, it just displays the output of various PowerShell commands in a graphical format.  So each time you ask the EMC to do anything at all, what you’re really doing is waiting for it to create the corresponding PowerShell commands, evoke and run them, and then take the results and spit them back out on the screen for you.  For more complex tasks that are going to take some time anyway (like multi-mailbox move operations), this isn’t such a bad thing to deal with.  The GUI components make that job easier, and don’t add a huge amount of time to the overall process.  But for other operations, like getting a listing of all Storage Groups assigned to a particular server, the overhead in delays for getting the info and formatting it into the MMC3 GUI interface can mean the processes takes several times longer to perform in the EMC than it would at the command line.

Secondly, some techniques could never be performed inside of a GUI in any version of Exchange.  Database consistency checking and error correction were always done from the command line, and therefore it was logical to build those routines into PowerShell and the EMS as the newer versions of Exchange evolved.  By leveraging the way cmdlets (PowerShell code snippets) worked, much more complex database control and corrective action sequences could be piped through a single set of commands.  This lets administrators do more with fewer keystrokes, and opens up a whole new world to 3rd-Party software platforms who found that batch files just couldn’t cut it for what they needed to do.

Finally, the same way that cmdlets can expand what can be done within the framework of a script for things that were always command-line based; they can also allow administrators to automated a lot of their day-to-day work as well.  Prior to Exchange 2007, setting up users and mailboxes was a rather straight-forward process, but required that you interact with a series of GUI’s to get it done.  This took up extra time, and also introduced another level of potential errors every time you opened up another GUI.  Granted, this did not tend to lead to a lot of issues for experienced administrators, but even the most seasoned pro is going to slip up if they have to click in the same spot, over and over, several dozen times a week.  PowerShell allows for the creation of complex scripts that can leverage cmdlets, VB and C# commands and other attributes bound into single executable files.  This means that a set of operations can be crafted, tested and saved, then run over and over as required.  Less moving parts means less chance for errors, and portability means that a more experienced administrator can craft scripts for folks who may need to run repetitive tasks but not have the skills to work with cmdlets yet.  Entire online communities have sprung up to facilitate cooperative efforts on PowerShell scripts and to share what worked and what didn’t for various Exchange-related tasks.

Speed, efficiency and community interaction are just three components of what PowerShell can do to assist the average Exchange Engineer or Administrator.  Since the trend toward leveraging PowerShell and the EMS continues into Exchange 2010 (scheduled for release later this year), getting on-board with PowerShell tools now will build a knowledge-base that will grow with you as you continue to leverage new and better Exchange platforms.

Net Neutrality and EAS

Mobile messaging and collaboration makes for a big, bright world in business today. What was once the domain of a single service provider (Research in Motion - RIM) has evolved into a robust set of platforms to convey email, appointments and contacts from one device to another.  Blackberries, Windows Mobile devices, iPhones, Android phones and so many other systems can communicate either directly or through a proxy to a Microsoft Exchange platform.  This unleashes the workforce and allows for your people to be where they need to be in order to work, instead of where they have to be just to talk to each other through the email system.

Net Neutrality is the idea that no matter what the network provider offers in terms of services and software, you should be able to use the devices of your choice and the platforms of your choice on those networks.  It’s a great theory, but putting it into practice is causing some issues along the way.  The FCC set forth a set of basic rules that they wanted carriers to follow, and in the greater sphere of comments, they were well received.  They recently added in two more proposed rules that directly impact cellular networks (digital broadband) and the services that run across it – including Exchange Active Sync (EAS).

You can get a rundown of the entire proposed rule set in this article, but the two that directly impact EAS most are:

5. Broadband providers cannot block or degrade lawful traffic over their networks, favor certain content or applications over others and cannot "disfavor an Internet service just because it competes with a similar service offered by that broadband provider."

On the surface, this looks like a standard anti-competitive rule.  In reality, however, many service providers in the cellular world are viciously blocking competing technologies, and their claim is that forcing neutrality will destroy their business.  EAS is a great example of this phenomenon, as not that long ago many providers didn’t allow that traffic on their mobile networks.  Mostly, this was due to the fact that they wanted to pus their own version of enterprise email synchronization (such as Sprint’s ill-fated attempt on the earlier Palm Treo devices).  Eventually, the need to allow this traffic or lose business to other devices and networks overrode the desire to use and sell their own platform, but that took a great deal of time, and lead to quite a bit of bad press and back-end attempts to circumvent the blocks.  By forcing mobile providers to allow all valid and legal traffic, the atmosphere for open communication standards will grow and more people will be able to take advantage of more technologies.

6.Broadband providers must be transparent about the service they are providing and how they are running their networks.

Proprietary networks are nothing new, but trying to create an EAS client for a phone on a network that actively blocks your ability to figure out how it sends and receives data makes this close to impossible.  Some providers have blocked all traffic they do not wish to have on their networks by simply making it very difficult – or nearly impossible – to figure out how a 3rd-party tool can possibly communicate with it.

I’m of two minds on these proposed rules.  On one side, EAS and other technologies require open, transparent communications platforms to work. Exchange can communicate with a whole world of different vendors’ mobile applications, but only if those apps can talk to the Exchange Server.  On the other side, competition drives better software and platforms.  If it wasn’t for all the things you can only do (or could only do) on an iPhone, RIM and Google would never have had the impetus to push their own platforms to new heights, and we’d still be staring at plain-text emails on black and white Blackberry devices.

It’s going to be a very loud fall season as the mobile providers and the FCC battle out these proposed rules.  The end result will have a huge effect, either good or bad, on how flexible and feasible your mobile Exchange platform plans will be. Competition is a good thing, but it cannot be forced on the market at the expense of profits.  There must be a way to balance these scales, and it will need to be found before Net Neutrality can be forged in the mobile marketplace.