Microsoft Exchange and Blackberry Server Specialists

SEMblog

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

Case Study 1 - Three Men and a Little Server

This case study is a little different from the normal deployments I do, because it is a very small installation - only three users. However it is a very high net worth deployment, and has shown to be very successful.

Background

Three people run a company providing professional services to much larger companies. All three live out in the countryside with their families.
The company doesn't have a central office, each spend most of their time with clients, or at home in a study type area.
At the time I was asked to assist, they were using a hosted Exchange solution and files were being stored all over the place. It was becoming a nightmare to manage.

The also wanted to do something about the speed.
Being in the countryside, broadband speed is an issue. None of the three homes has a speed fast enough to run a server. With young families, there was also the concern of other demands on the computer and broadband connection. This introduces problems with dealing with network security and generally trying to split the business computer work from leisure.

I was asked to come up with some kind of solution that would give them a decent speed where ever they are, and also protect their and the client data.

The Solution

The solution I proposed, and implemented in late 2010 was very simple, but highly effective.

Hardware: This was a single Dell PowerEdge server, Eight disks, 30gb of RAM - with space for more.

Software: On to the bare metal I installed VMWARE vSphere 4.1
Then in to the virtual platform I installed six virtual machines:

VM 1: A Linux based firewall called pfSense. This protected the other machines.
VM 2: SBS 2008 Premium. Exchange 2007, commercial SSL certificate, all features enabled and turned on.
VM 3: Windows 2008. SQL Server. This also had BES Express and a monitoring tool for the VMWARE platform from Veeam.

VM 4 - 6: Windows 7 Professional. All three were identical, with Office, Adobe Acrobat Reader, AV and other tools installed.

Each of the workstation installations also had Dropbox installed.

The server was installed in to a data centre, where the data centre was able to provide backup storage for the server. Backup was provided by Backup Assist.

In Operation

The key to this implementation was the Terminal Services gateway feature of Windows 2008 and the RWW feature of SBS 2008.

What this allowed each staff member to do was connect to their virtual desktop in the data centre, from any machine and work. If they had to stop what they were doing, they could just disconnect, and come back to it.
This meant that working on the train, or in a client site was perfectly possible. Each of them had a laptop with 3g cards, wireless etc, so could get access back to the server easily. If the connection dropped for any reason, reconnecting would pick up from where they started.

Dropbox was used to allow files to be moved between the virtual workstations in the data centre and their personal computer. This could be to work on a file locally, copy it to a USB stick, because it contained video or for printing. It was found that the printers at home didn't like RDP very much, so printing was disabled.

The Blackberry devices gave access to email, and crucially the little known feature that allows access to the file system.

Benefits of This Solution

The server was in a secure location, not dependant on one place, with power or broadband issues. Email was quick, and filtering done in the data centre.
No more emailing files to each other, they could be just copied to a network share. This made collaboration much easier.
As all data was stored in the data centre, if the laptop was stolen, was damaged or simply failed, the loss would be small and it would be easy to get up and running again.

At home, if someone was relegated to a child's computer because they were using Daddy's computer for "homework", then the impact was negligible, as all the computer required was the RDP client. The home broadband speed was fine for this kind of work. No concerns with data security while the children are on the computer, as it was all in the data centre.

This also means that the home and roaming computers can be anything, they don't have to worry about compatibility with the "office" . It just needs to be something recent that has an RDP client.

RDP clients are common, one staff member is using it with an Apple iPad. Other tablets are being investigated, and I wouldn't be surprised if a Blackberry Playbook was used when those are released.

Terminal Services

We did consider using a full terminal server, but this was discounted for a number of reasons, the main one being cost of licencing it. However should the company grow, a terminal server can be quickly added to the deployment with little fuss.

Conclusion

A compact single server installation has proven to be very cost effective and given these users performance and security that they are very happy with.

Case Study Week

I have a number of case studies written up for various technologies that I am going to post on the blog over this week. They cover both SBS 2008 as well as the full Exchange 2010 product, and how to show what you can do with these products to enhance your business.

Usernames Tried During Authenticated User Attack - Updated

Back in June 2009, I blogged on an authenticated user attack on a client's server.
http://blog.sembee.co.uk/post/Usernames-Tried-During-Authenticated-User-Attack.aspx

As part of that blog post, I included the list of names that were attempted.

The same server was attacked again in the last few days, and the list of usernames attempted changed very slightly. I have included the list below.
So quaint that they were tried in alphabetical order as well.

This list, along with the list from the original attack should be a list of usernames and passwords that you should avoid using, simply to ensure that you don't expose more than is necessary to this kind of attack.

www
vm
visitor
user
testuser
test
sysadmin
sysadm
support
supervisor
sales
operator
office
marketing
mail
info
guest
fax
backup
anonymous
admin
adm
account

Exchange 2010 Database White Space

With Exchange 2007 and older versions, one of the key elements that an Exchange administrator needed to keep an eye on, and caused confusion for newcomers to Exchange was the amount of white space in the database.
This is reported as free space in the event viewer via event ID 1221 during the night and is the result of content being removed from the database by the online defrag process.

I have written about this event ID and the white space elsewhere:
http://www.amset.info/exchange/event1221.asp

With Exchange 2010, the behaviour of the database has changed.
Instead of doing a online defrag during a fixed time window, it now does it constantly. This means that content that has passed the deleted item retention period, is removed from the database shortly afterwards, rather than waiting for the next online defrag window.

However because the process is running constantly, event ID 1221 isn't written to the event log. Therefore an administrator may not have a clue as to how much of the database is white space, and how much is actual content.

This question can be easily answered, using EMS, as the amount of free space in the database is available via get-mailboxdatabase -Status:

Get-MailboxDatabase -Status | Select Servername, Name, AvailableNewMailboxSpace

This command will show you the name of the Server the database is mounted on, the name of the database (which is unique across the Exchange org with Exchange 2010) and the mount of space available in the database for new content.
The result will be something along the lines of this:

ServerName                     Name                          AvailableNewMailboxSpace
----------                          ----                            ------------------------
SMB-A                             Mailbox Database         27.75 MB (29,097,984 bytes)

The command used -get-mailboxdatabase -status can provide quite a bit of information about the databases in your Exchange org, use the |fl command to see the full list.

RPC Client Access Array

One of the new features with Exchange 2010 is the client access array. When configured correctly, this is quite a useful feature. In my view it is something that should be configured on all Exchange 2010 servers, even on a single server deployment.

Background

The full explanation of the CAS Array feature is available on Technet, but in short, the reason it was introduced was due to the changes in the way connections to the database are now handled. With Exchange 2007 and older, Outlook connected directly to the mailbox server (unless using Outlook Anywhere). With Exchange 2010 all clients now connect to the CAS servers. The CAS servers then manage the connection to the database.
With the Database Availability Group (DAG) meaning that an active mailbox could be moved between servers easily, connecting directly to the mailbox server wasn't really practical.

The simple way to think of a CAS array is like a virtual Exchange server. Clients see this virtual name instead of the actual name of either the CAS server or the mailbox server.

Why you should configure a CAS Array

If you are deploying multiple CAS servers, or a DAG, then a CAS array is pretty much mandatory. However if you are on a single server, or are separating the mailbox and the CAS role on to separate machines, then a CAS array is still of value.
If you have ever done a migration or disaster recovery, one of the key pain points has been getting Outlook to point to the new server in a timely manner. As long as the original server was alive, then Outlook will redirect to the correct server automatically. During a migration though, it may not be possible to get all clients to connect to the old server in a timely manner and the old server has to be removed.

However as the CAS array is simply a DNS entry and a small configuration in Exchange, it is completely under the control of the network administrator. A change to the DNS will make all Outlook clients point to another server.

If there is a possibility at any time in the future of additional Exchange servers being introduced, or the CAS role moved to its own server, the use of the CAS array from the start will become invaluable for easing that transition. All MAPI clients will use it, so as well as Outlook, this can also include things like Blackberry Enterprise Server.

CAS Array Configuration Notes

Ideally the CAS array should be configured before any mailboxes are moved to Exchange 2010. If you don't, then the clients that are moved will use the true name of the CAS server, and even after the CAS array has been configured, they will not change unless the mailbox is moved between servers or the Outlook profile is changed.
If CAS Array is therefore introduced retrospectively, it can produce mixed results if all clients haven't been updated with the new value some how.

You can use the CAS array with Network Load Balancing (NLB), but if the server  has all of the roles and is also a DAG member, then you must use an external load balancer. Using NLB on the same server as the DAG is not supported.

A CAS array cannot go across Active Directory sites. Therefore if you are doing a two host DAG, with the second (passive) host in a data centre or similar, and have separated the AD sites, you will need two CAS arrays. In the event of a full failover, you will need to change both the CAS Array value on the database and the DNS. While this is a manual intervention, it does mean the process remains under your control.

The CAS array host does not have to be in the SSL certificate, simply because Outlook doesn't make any http connections to that host name.
You should not use the same host name for other services, particularly anything that is being accessed externally (like OWA), but you can use the same IP address and therefore NLB virtual IP.
For example, you could use outlook.example.local as the CAS Array host, then mail.example.com for OWA, SMTP, Outlook Anywhere etc.
If your internal and external domain are the same, then ensure the internal name doesn’t resolve, externally so no wildcard in the domain etc. Failure to do so will result in a confused Outlook, and will probably mean Outlook Anywhere has performance issues, if it connects at all.

Finally, on the DNS entry for the CAS array, turn the TTL time down. This will ensure that if you do have to change the host name IP address, it is picked up quickly.

Background and Configuration of the CAS Array: http://technet.microsoft.com/en-us/library/ee332317.aspx