Simply having the Client Access service up and running automatically turns on the ability to pipe out Exchange 2007 email, contacts, tasks and calendar items to portable mobile devices.  Not only can one get their email on their mobile phone with Exchange 2007, there are some added benefits for Exchange 2007 Administrators.

Just like Exchange 2003, 2007 has the Direct Push technology.  Direct Push enables the mobile device user to receive mail as it is sent to them.  They do not have to wait for a specific time to synchronize, or perform this manually, in order to retrieve email.

Many Windows Mobile devices are setup, by default, to get email in increments of 10 to 15 minutes, but this can easily be changed to “As mail arrives…” (or phrases of that nature).

Setting up a mobile device to connect to Exchange 2007 can be relatively simple.  All that is required is the username and password of the Exchange user, the Windows Enabled handheld device, the public IP or DNS name of the Client Access Service, and a digital certificate.

As an important item of note, you can either create your own certificate in-house, provided you are running the Certificate Services within your domain; or buy a certificate from a registrar.

For smaller businesses that do not maintain and create their own digital certificates, it is much easier to purchase one from a group like Thawte or GoDaddy, and associate it with your Exchange Public IP address.

Although there is the additional cost of buying a certificate, Windows Mobile devices are preprogrammed to recognize registrars like Thawte and GoDaddy and can reduce the deployment time, by bypassing the self-signed certificate portion.  Make certain to test the setup of a mobile device with your certificate, before deploying the ActiveSync service to the rest of your corporate element.

True enough, there are other amenities given to the handheld user, such as the ability to receive HTML formatted email and Task synchronization.  With the synchronization of the Outlook Calendar, users can keep up with their Exchange enabled appointments and meetings.  However, the real benefit to running Exchange 2007 are the management features for control over Windows Mobile devices.

From within the Exchange 2007 Console, an administrator can configure a wide variety of options for users with ActiveSync enabled on their Exchange User Account.  You can set the maximum size of attachments one may download to their mobile device.

You can allow, or not allow, simple passwords; as well as minimum password length.  Password history can also be put in place, so that a user cannot reuse the same password each time they have to change it.

At this point, these features may sound interesting or perhaps not as helpful as you would want.  “What if my user loses their Windows smart phone?”, you might ask.  Now there is a question that many systems administrators and business people alike would like an answer to.

With Exchange 2007 controlling your Windows Mobile enabled device, you have a couple of really good security options in this respect.  One can manually setup a device wipe, so that the next time the phone “calls home” so synchronize its email, Exchange will send out a signal to wipe the device, and reset to the default settings.  The user’s email, contact information, and other data they created, is now gone.

To perform a device wipe, go into the Exchange Management Console (this is presuming that you are paired up with the Exchange Organization Administrator role).  Go into the Recipient Configuration, and choose Mailbox.  Locate and choose the user with the device in question.  Now look on the right hand side of the Console, which contains several links for actions.

Click on the one that shows Manage Mobile Device.  Choose the device to be wiped of data.  Now locate and click on Clear, in the Actions area.  The next time that particular device polls for updated email, or other Exchange information, that user’s data will be wiped off the lost mobile device.

Should this not appeal to you as the best option, you may also setup an Exchange ActiveSync policy that will wipe the device if someone tried to guess their password more than a specified amount of times.

If a user loses their phone, and realizes it immediately, the aforementioned device wipe is a good utility to use.  However, should someone not be aware that their smart phone is missing, then having an ActiveSync policy, with the password settings, in place is imperative to help stave off data theft or loss.

Exchange 2007 does add some enticing features with respect to Windows Mobile technology.  Though it appears to do this more so on the administrative side, than that of the end user.  In either case, it is beneficial to keep with the Windows platform handheld devices when running Exchange 2007 as the messaging solution.

Thanks for reading, check out Help Desk Geek - Help Desk Tips For IT Pros for more WordPress news!

The home Windows computer user probably does not face the licensing fiasco that businesses have to overcome.  If you have a single user computer in a home type setting, the licensing is pretty straightforward.  One copy of a Windows operating system, one copy of Microsoft Office, and maybe a copy of One Care for computer security, might round out the licenses on one computer.

Do take into account that purchasing a single copy of One Care covers the licensing for three computers.  If you buy a retail box copy of this particular software there is text on the retail box copy stating the three computer count.

So far, the licensing sounds easy.  It is a one for one license to computer ratio, with the exception of the One Care product.  Now let’s move over into the business arena.  In this instance, we are focusing on purchasing Microsoft Exchange licensing.

For purposes of illustration, we are tasked with purchasing new Exchange 2007 server software and licensing for 200 users:  170 office based employees and 30 traveling sales type employees.  We will be going off the assumption that we already have three 64-bit Windows 2003 servers in production status.

First, we have to determine what core pieces of Exchange we require.  Do we need Exchange Server 2007 Standard or Enterprise?  For the most part, Server Standard can easily cover 200 users, mailbox wise.  This covers five databases for each server Mailbox role.

So if we have one Mailbox role in production, we can have five different databases.  We will also purchase an additional copy of Exchange Standard to put on a separate server for the Client Access service, in particular for the remote employees (Outlook Web Access and Windows Mobile enabled devices).  It appears that this is a practical solution at this point.

However, Exchange 2007 Server Enterprise has a 50 database availability per Mailbox role, and adds clustering.  While our small server does not have a current need for clustering, nor a 50 database ceiling, unified messaging has been a desire of this company.

However, the client licensing determines the accessibility of the extra features, not the server license.  The main question here is whether or not company growth will require the greater amount of databases.  It would appear at this point, and the near future, that this is not the case.

Since we are leaning towards unified messaging, but do not foresee many databases, we can plan on purchasing two copies of Exchange 2007 Server Standard.  Considering each database hold up to sixteen terabytes of data, five databases should cover 200 users.

We will be placing the Mailbox role and Unified Messaging service on one server, and be using the other for the Client Access role (to include the remote users).  With the core portion of Exchange Server licensing covered, what about the client licenses?

The client licensing is the more detailed part of the licensing purchasing plan.  Standard Client Access Licensing has to be purchased for each person accessing Exchange.

Also, since we desired the Unified Messaging piece, Enterprise Client licensing has to be purchased for each employee who will be using this messaging service.  Since the 170 employees, who are tied to the office, will be using the Unified Messaging, 170 Enterprise Client Access Licenses are needed for them.

For the remote workforce, who desire Outlook Web Access, and email on their handheld devices, 30 Standard Client Access Licenses will cover their needs.  It looks like everything is wrapped up at this point.

Unfortunately, we are not quite finished.  Each employee who requires an Enterprise Client license, must also have a Standard license purchased to accompany it.  The Enterprise Client is actually an add-on piece to the Standard license, and not a separate product.

Now let’s look at a cost breakdown of what we would be paying out in licensing fees (approximate current retail pricing).  Two copies of Exchange Server Standard ($700 per copy), 170 Enterprise Client Access Licenses ($65 for each Standard license, plus $35 for the Enterprise portion), and 30 Standard Client Access Licenses ($65 each); all for a grand total of $20,350.

Hopefully, this will give a better understanding of what Exchange licensing can mean for individual organizations, both in accessibility and cost.

Thanks for reading, check out Help Desk Geek - Help Desk Tips For IT Pros for more WordPress news!

When planning for Exchange 2007, you need to decide early on what server roles you require, and how many servers you will need to accomplish this.  Exchange 2007 is broken up into the Mailbox, Client Access, Hub Transport, Edge Transport, and Unified Messaging roles.

You can run all of these roles on a single server, or you can spread them out with an Edge Transport server, a Client Access server, one for Unified Messaging (if you intend to use this functionality), and one server containing the Hub transport and Mailbox roles.  The best approach is to figure out how many servers you are able to maintain in your current network infrastructure.

Keep in mind that when you are initially configuring the hardware for your Exchange 2007 environment, more hardware crammed into a server, is not always better.  Exchange 2007 is 64-bit, will be running on Windows Server 64-bit, and makes excellent use of 64-bit processors.  Because of this, you are not limited to the 4GB memory ceiling in the previous 32-bit Windows environment.

However, processors, specifically the number of cores, demand extra attention due to the specifics of what server roles you are using on what hardware.  A Microsoft TechNet article (seen here) gives a break down of how many processor cores per server role, are recommended (not an absolute rule).  For instance, the Mailbox role supports a minimum of a single processor core, but a maximum recommendation of twelve cores.

So you could have a server with a single processor, with a single core, which is not common for new hardware on today’s market; or you could run a server with six, dual-core processors.  A practical choice would be a pair of quad-core processors, which could safely handle the processing requirements for the Mailbox role.

That said, what if you wanted to run multiple roles on one server?  In this instance, your limitation, if you will, is the smallest amount of maximum recommended processor cores for a server role.  For example, while the Mailbox role can utilize twelve cores, the Client Access role tops off at six.  If you had the Client Access role running alongside the Mailbox role, a practice measure is to have two or three dual-core processors.

Setting aside the processor matter, we need to examine the server’s memory needs.  A partner article to the previous TechNet post, gives the reader suggestions for the amount of memory needed for each server role.  All server roles prefer a minimum of 2GB each, but again, this is the base requirement.  Combining server roles asks for a minimum of 4GB of RAM.

The article covering the Exchange 2007 memory requirements (seen here) does a fair job of giving a technician the basic memory specifications, however, one will have to carefully examine their organization in order to fully calculate RAM usage.  While there are statements, in the article, to effect of measuring email use against the amount of needed memory, be careful not to simply install the calculated result.

If your number of users is around 300 and your math leads you to 16GB of RAM, why not go with 20GB of RAM?  The monetary difference is less than in years past, and having additional memory is an easy safety net to have in place prior to deployment.

In the realm of non-volatile storage, the hard drive space you will need starts with what you are currently using, plus the outlook for future usage.  Since hard drives are continually lowering in cost, this is another instance where buying additional hardware is a good measure.  There are some special considerations with Exchange 2007 when is comes to storage though.

As with the other hardware recommendations, Microsoft’s TechNet contains a posting (seen here) for the storage considerations with Exchange 2007.  Among other matters, it points out four RAID types, and how each of them performs with Exchange 2007.  This subject requires scrutiny on the part of the system administrators because they must decide if performance, storage capacity, or disk fault tolerance is the most important.

Keep in mind that the TechNet article appears to be leaning towards fair sized deployments of Exchange 2007.  If you have a smaller system setup that supports 50 mailboxes, and the mailbox databases reside on a RAID 1 mirrored disk pair, you may not necessarily notice any performance difference than on a RAID 5 disk array.  Of course you may want more redundancy than a simple pair of hard drives.

In addition to the RAID considerations and physical disk size, what about the mailbox sizes?  Does your current email system have caps in place for individual mailboxes?  Do you have a universal limit on all mailboxes or are the caps mitigated by employee position or job function?

Perhaps someone on a shop floor, that only receives production orders, can function fine on a mailbox cap of 500 MB.  However, someone working in the marketing department may require a larger cap in order to track emails with design specification attachments.

With Exchange 2007, you have a greater availability of storage groups, than Exchange 2003.  With the Enterprise edition of 2007, you can have up to 50 storage groups for each server.  In practical administration terms, you could allocate one storage group for each individual department in a company, and manage the storage group, instead of individual mailboxes.  Doing so could cut down on the time spent to size storage accordingly by focusing on consolidated groups rather than the hand count of each user’s mailbox.

So let’s wrap this up with a real world example.

One small manufacturing company, 100 mailboxes of varying sizes, no current mailbox cap (except for the Exchange 5.5, 16GB database limit), multiple Outlook PST files on varying end user computers, and an aging Exchange 5.5 server (A single 500 MHz Pentium 3 processor, 1GB of RAM, and a RAID 1 36GB hard drive pair).

Total storage required, 15GB (current Exchange 5.5 database mail store), plus 40GB worth of email in various PST files throughout the company.  In this particular instance, the Postini service is already in place for perimeter email spam and virus protection, and it will be used in place of the Edge Transport server role.

Email server solution:  New pair of servers with the assumption of other service running on them (DNS service, security software, defragmentation software service, and other monitoring utilities).  The first server contains the Exchange 2007 Hub Transport and Mailbox server roles.

This server is configured with a pair of Pentium 4 Dual-Core processors (total of 4 cores), 16GB of RAM, and a pair of 72GB hard drives (for the operating system and Exchange 2007 log files, in RAID 1).  The actual Exchange mailbox stores will be housed on a fiber attached storage array with a RAID 1/0 setup.

Four 146GB hard drives will provide the fault tolerance, performance, and space for the combination of the original email store plus the email unloaded from the PST files.  The fiber attached storage array has four open bays for future hard disk expansion.

Three initial storage groups will be created within the Mailbox role, labeled as High, Medium, and Low.  These are specifically named due to the nature of employee’s email usage.  People using the least amount of email storage are placed in the Low storage group, the heaviest users in the High group, and everyone else falls in the Medium category.

The second server will be the Client Access server role piece.  It is configured with a pair of Pentium 4, dual-core processors, 6GB of RAM, and a pair of 72GB hard drives in a RAID 1 configuration.  Keeping the Client Access role separate lessens the processor load on the Mailbox server. This server will house additional log files from the Client Access role, as well as serving as a future connection point for Windows Mobile enabled devices.

Referenced Articles:

http://technet.microsoft.com/en-us/library/aa998874.aspx – Exchange 2007, Planning Processor Configurations

http://technet.microsoft.com/en-us/library/bb738124.aspx – Exchange 2007, Planning Memory Configurations

http://technet.microsoft.com/en-us/library/bb738146.aspx – Exchange 2007, Storage Technology

Thanks for reading, check out Help Desk Geek - Help Desk Tips For IT Pros for more WordPress news!

The worst thing about the whole thing is that the columns don’t even show up when you go to the Add/Remove Columns dialog in Exchange.

So how can you find out the size of a users mailbox in Exchange 2007? Well, until they bring back the columns in a future service pack, you have to use the command line.

For example, here is the command line you would use to get a list of all mailboxes with their sizes sorted from biggest to smallest. It will also give you the number of items in the mailbox and will list the sizes in MB.

Get-MailboxStatistics | Sort-Object TotalItemSize -Descending | ft DisplayName,@{label=”TotalItemSize(MB)”;expression={$_.TotalItemSize.Value.ToMB()}},ItemCount

If the above command does not work for some reason, you can also try this one:

Get-MailboxStatistics -Database “Mailbox Database” | Sort -Property TotalItemsize | Format-Table DisplayName, LastLoggedOnUserAccount, ItemCount, @{expression={$_.totalitemsize.value.ToMB()};label=”Size(MB)”}, LastLogonTime, LastLogoffTime

Note that if you just want to see the mailbox size of one mailbox, you can simply go to the Properties of the mailbox and view the size and number of items on the General tab.

One last way you can access this information is to install Exchange 2003 Management Tools on a different server and use it to view the size of Exchange 2007 mailboxes. Make sure not to use the tool to perform any management tasks, only to view information about mailboxes.

Hopefully future versions or service packs of Exchange 2007 will fix this problem, but for now you can either use the command line or use the Exchange 2003 Management Tools! Enjoy!

Thanks for reading, check out Help Desk Geek - Help Desk Tips For IT Pros for more WordPress news!