I attended the Microsoft Certified Master : Exchange 2007, rotation 2; prior to attending I had the good fortune to be able to talk to previous Ranger/MCM candidates within Microsoft, who helped prepare me for the program. I thought it would be a good idea to consolidate this information, along with my own advice for future rotations.
I will leave it to others to talk about what the MCM program is and the and benefits of attending (there are many!); this post is simply to outline what to expect and how to cope with it :)
There are five flavours of MCM that currently exist. Although they loosely follow the same structure they are also very different. This post is regarding my experiences from attending the Exchange version…
So, one of the first things to know about MCM is that it’s essentially three weeks of your life dedicated to Exchange. If you want to stand any chance at being successful it is VITAL that you have cleared this time, both with your customers and your FAMILY!! – this is especially true if you are attending from Europe; the time zone and class schedule makes communication with family and friends quite a challenge. Make sure you set their expectations that you haven’t died or been abducted by aliens during the three weeks.
Be prepared for long and difficult days, some days during my rotation I would be awake at 7am and not get back to my apartment until 10pm. On average most days tend to run from 8am to 6pm of classroom teaching, then there are homework assignments and often there are recommended labs to complete. There are three exams to complete, studying for these exams usually takes up most of the weekend, so its probably not a great idea to plan anything too exciting for the weekend – we typically did a mixture of self study throughout the weekend and a group white board session on Sunday afternoon which gave everyone a chance to combine their knowledge and talk about what we “thought” might be on the exam (we were almost always wrong!)
It sounds like hard work, and it is, but its also great fun – honest :) If you enjoy technology and working with Exchange, the chance to spend so much time focused on a single product is actually really good fun – especially with a group of like minded people :)
The Exchange program has a great reading list – however it is a bit on the large side. Roughly it suggests you read the help file and every blog or whitepaper published on Exchange 2007. The approach I took, which seemed to work well for me, was to concentrate on areas I had the least amount of experience with. Once in class the content is presented very quickly and if you get lost there is very little time to recover, likewise the labs can be complex – Greg’s approach is to describe the end goal of the lab and not give you step-by-step instructions. This is great and allows more flexibility in the labs; however it also means that you may struggle if that area of technology is new to you.
Once I had identified my areas of weakness I printed out white papers and blogs etc, which I kept with me in my laptop case. Rather than read a book on the train or plane, I would read about UM or ILM. I still found these topics tough, but without the pre-reading I would have been totally lost!.
In addition to Exchange there are some additional skills that will make your time at MCM less traumatic. I hope Greg doesn't mind that I list these, but I feel that some exposure and familiarity with the following technologies would help all candidates…
ISA is used predominantly during the CAS sessions and lab work – its not necessary to be an ISA expert, but some hands on practice configuring publishing rules and listeners would have helped me beforehand – likewise understanding what troubleshooting processes and features to use would have been handy.
It also appears compulsory to say the phrase “Green Ticky Ticky” whenever something goes well in ISA (Everyone in R2 will understand that! - and so will you if you go through a rotation!)
A large proportion of my rotation ended up staying at the Redmond Trails, which are essentially a collection of self catering apartments about a 25 minute walk from campus. You will not spend long in your chosen accommodation, so it is important to be realistic regarding the items you buy. It’s unlikely you will have much time to prepare food or cook – we literally just had coffee and ready meals in our apartment. Pretty much all of the time was spent studying to ensure we passed the exams. The apartments usually have fast internet access and Microsoft FTE’s can access their lab environments via the corp VPN.
Make sure that you know how long it takes to get to class, there is a no tolerance approach to lateness; on your first late you will be made to do something appropriately embarrassing (this is usually recorded!) – but be under no illusions, class will start regardless of you being there or not. Since a huge part of the exams are based on the verbal information provided by the instructors, your instructor may choose to give the rest of the class a bit of “important” information in your absence! – you may also find that additional homework is received for the entire group due to one person being late – DO NOT BE LATE! :)
My flatmate and I decided to walk whenever possible – you spend so much time cooped up inside the classroom it seemed like a good idea to get some fresh air and exercise whenever possible. Be warned however, its Redmond – that means it rains – a lot! so be prepared :)
Class usually begins on a Monday so try to get up to campus on the Sunday beforehand so that you know where you are going on Monday morning – there is nothing worse than frantically racing around campus trying to find a building or somewhere to park! Get there early, grab a coffee and try to relax – its going to be a busy day :)
Unless you live in Redmond or somewhere close, it’s likely that you will experience some degree of jetlag during the first week of MCM. Previously I had tried many things to get over jetlag, the most suitable for me is just to adopt the new time zone as quickly as possible and deal with a few days of being incredibly tired. A good friend of mine who attended the OCS MCM rotation in January suggested that rather than fight the jetlag, study when you can and sleep when you can. For most of the European candidates this means getting up at 4am each day, doing some study from the previous day’s class and then going to sleep at 7pm after class. At the end of the first week you have pretty much adjusted anyway. Those that didn’t adopt this technique found that they were studying when their bodies wanted to go sleep and they were not able to remember a great deal from their study sessions.
Don't forget you are there for three weeks – its an endurance game, no point in pushing yourself to breaking point in the first few days!!
Dealing with Jetlag
One of the most important aspects of attending MCM is the social side. You will be sitting in a room with a number of other Exchange candidates – you probably have had a very similar career path to the guy sitting next to you. It’s also highly likely that you will learn a huge amount from the people sitting around you - as well as the guy standing at the front of the class. Some of the class discussions are fascinating – everyone sitting in that room with you has earned their place, however they may have a totally different perspective than you – taking the time to participate and learn from these discussions is highly rewarding.
Greg also runs a couple of nights out, all of which are great fun and allow you to get to know your fellow candidates in a more social setting. All of you are in the same boat and will go through the same highs and lows as each other. By the end of your time at MCM you will undoubtedly have made several new friends.
This is one area that concerned me before I got to MCM. If these classes are 12 hours and we have homework, study and exams – how will I cope for three weeks?
The time passes incredibly quickly, but it’s vitally important to keep yourself alert and well rested. Get as much sleep as you possibly can and ensure that you keep yourself well hydrated throughout each day. We all know we should do this – right? But it’s all too easy to forget. There are frequent breaks – make the most of them – don’t be afraid to request a break, if you need one…. the chances are everyone else does too!.
The classroom also acts like a Petri dish for colds and illness – in my rotation we had sixteen candidates, half of which had flown long-haul from around the world. Then we all sat together for 12 hours a day or more in a room with no windows! – combined with lack of sleep and the stress of the program led to many of us catching a cold (including Greg!). So, make sure you have cold medication, headache tablets etc – be prepared! There is nothing worse than trying to absorb information when you’re not feeling well and you have an exam on Monday!
The exams are multiple choice, closed book and computer based - but don’t expect MCP style questions. These exams can be tough, very tough! There were times during our rotation where those little multiple choice exams seemed impossible!
There is no easy way to pass the exams; the best advice is to pay attention during class and MAKE NOTES! Some people like study groups, others prefer to study alone. During my rotation we spent several hours each weekend going through topics on the whiteboard, checking that our understanding was correct. We also attempted to guess what likely questions would be asked on each topic – this proved largely unsuccessful (devious instructors!) but participating in these group sessions definitely help me; usually I prefer to study alone, so I was surprised to enjoy the group sessions. My advice is that if you typically study alone, why not study the material then head off into class for a short while and see how you get on in a group. Besides, it might make a nice break from your apartment!
Another tip that I found useful was during the week as you come across areas that you think might be on the exam, write them in marker pen on a sheet of A4, then tape it to the wall. I found this particularly effective for remembering lists; although our apartment did look a bit odd after three weeks...
Pay attention to the slide decks; not only might they have links on them (questions can come from the slides, notes, links or verbal content!) but quite often the slide notes are very revealing :)
This sorts the men from the boys! there is no easy way through – it’s tough. Without giving too much away, the test is essentially made up of a virtual environment containing a number of servers, routers and other infrastructure which has various things broken. You are given multiple tasks to complete within the lab which will require that you fix some of the breaks. Just to make things a little harder, you have a time limit which generally means that if you attempt to fix all of the breaks you will run out of time. The real skill is in determining exactly what you need to fix in order to complete the tasks as quickly as possible.
A support background will definitely help here, although it’s essentially just about being logical and working through each problem as you find it. Those that are successful generally take a task approach, so rather than fixing everything, simply fix the minimum things required to complete that single task, then move on to the next. In our qual lab there was nothing that could be described as complicated – all of the problems had relatively easy fixes, however finding that simple fix might take an hour or more. It’s also worth remembering to check the basics, networking, DNS, AD – it’s amazing just how much chaos Greg can cause without actually doing much!
Take your notes electronically as you go. Various candidates advised me to do this after struggling to get their notes completed before the time ran out. To complete the qual lab, not only do you have to fix the breaks, you have to detail the changes you have made to get things working. Without these notes you will fail, if the notes are not complete or Greg is unable to understand them, you could also still fail! Your notes will also help you should you need to back out a change that you have made to the environment.
Its meant to be fun as well as a challenge. One of the guys from my rotation had an agreement with his daughter that he would take her toy “Theodore” with him everywhere he went for the three weeks and take pictures so that she could see what he had been up to. Theodore quickly turned into the class mascot…
Rotation 2’s mascot “Theodore” showing just how easy OCS is… :)
Both before and after attending MCM I would talk to people about the program. One of the most common comments I heard was that they would love to attend but they didn't think that they were ready yet.
After going through the program and surviving I have some advice for all of those people (you know who you are!) – if you have the opportunity to attend this course, do not pass it up because you think you might not make it – you probably know much more than you think you do already :)
MCM Exchange 2007 - rotation 2’s home for 3 weeks – I'm not entirely sure where we all were when this was taken…
If you are interested in attending Microsoft Certified Master (and you should be!) - I recommend you check out the following links…
PS. The pictures were all expertly taken by Morten Kjønnø
Posted by Neil Johnson, MCS UK, MCM Exchange 2007
Over the last 12 months I have had various occasions where I needed to quickly check the store.exe version installed on each mailbox server within the organisation.
Seemingly there is no way to do this directly via PowerShell or Exchange cmdlets.
Paul Flaherty has already written a great script to determine the SP and RU version of your exchange servers. Paul uses WMI to query the registry for installed hotfixes and Roll Up’s. I wanted to see the physical version of store.exe that was running on each server specifically, since we had a concern about how some RU’s had been applied.
On the surface this seemed like a really easy thing to do, just grab a list of Exchange servers, then grab the fileversion info from store.exe…
Well, yes and no. For the standalone mailbox servers this worked great, however for all of the clusters it failed, since the get-mailboxserver cmdlet returns the CMS name and under Server 2008 Clusters, all shares are scoped to the network name, since the admin C$ share is not part of the Exchange CMS, the cluster refuses to answer the CIFS request. However, after some digging I came up with a workaround by using the IP address. Since the IP address is bound to the node network interface it answers the CIFS query.
So, this is the script I came up with. Its a basic loop, that checks the file version information on the store.exe binary on each exchange server. I used ping to get the IP address, which works quickly and seems to give me what I wanted.
During the writing of this blog post it occurred to me that I could also use the ping reply status ($reply.status) to test if the CMS or Mailbox server was up or down, saving some time waiting for the GetVersionInfo call to timeout, but I will leave that for another day :)
The output of the script looks as follows…
[PS] C:\build\powershell>.\getstorever.ps1 Examining Store on MBXSERVER1...08.01.0336.000 Examining Store on MBXSERVER2...08.01.0336.000 Examining Store on MBXSERVER3...08.01.0336.000 Examining Store on MBXSERVER4...08.01.0336.000 Examining Store on MBXSERVER5...08.01.0336.000 Examining Store on MBXSERVER6...08.01.0336.000 Examining Store on MBXSERVER7...08.01.0240.005 Examining Store on MBXSERVER8...08.01.0336.000
Hopefully someone else out there will find this useful – its certainly saved me a couple of hours work today. It would be nice to change the formatting and have it output this data as a HTML table, but like the ping status, I will save that for another day…
I’m guessing that over the next few months IT managers are going to be pushing their staff really hard to justify any spend. ..and projects to upgrade to Exchange Server 2007 are not going to be immune. Clearly to have any chance of getting the go ahead for your deployment of Exchange Server 2007 you are going to need to be able to demonstrate significant advantages of its deployment and that’s going to centre around saving cash… (incidentally it’s no surprise that 3 out of the top 5 ‘Top Ten Reasons to Upgrade to Exchange Server 2007’ are based on saving money.)
So I thought I’d put together a few blogs about areas where you can prove that deploying Exchange Server 2007 will lead to saving your boss’ money.
Part 1 (Fewer Servers supporting More Mailboxes) “OK so it’s one thing being able to say that you can support more for less but it’s another proving it. So how do you prove that you actually save money by requiring fewer servers to support the same or more mailboxes?”
Part 2 (Make your backups more cost effective…) “One area it’s worth focusing on is backups. ..but I wouldn’t tackle backups on their own – I would tackle them in conjunction with your overall plans for compliance and availability.”
Part 3 (Storage) “Ah yes that old chestnut… SAN versus DAS – switch to DAS and save a load of money. It’s obvious right? Well I’m not sure. This is still a hot topic but the bottom line is that Exchange 2007 now gives us a lot more options about which storage we choose to support our Exchange data.”
Part 4 (Big Mailboxes) “OK so the idea of big mailboxes has become a viable option for a lot of organisations since Exchange Server 2007 was released and now that we are seeing real examples of deployments of mailboxes of multiple GBs there is more information around to make it more of a comfortable decision to deploy large mailboxes with Exchange Server.”
Part 5 (the Edge) “OK so I work for Microsoft but hey it’s worth a try …consider the Edge Transport role server as a replacement to other services in the perimeter.”
Part 6 (A few last ideas…) “...a few more ideas that are worth exploring...”
Doug Gowans
Exchange Server 2007 introduces many new and really well defined recipient types. One of them is the one my customer asked me about. The process to create a Shared Mailbox will create a disable Active Directory user as there is no point to have it - that is not the purpose of this recipient. On the old and still actual days of Exchange Server 2003 or older, when we created a Shared Mailbox we basically created an Active Directory account with an associated mailbox and those credentials would be shared within who needed to use it. What is the issue here? Security! Was never a good idea to more than one individual login with same credentials. Control on it would be inexistent.
So in Exchange Server 2007 what we have is a mailbox with a disabled user and in a way we can give access to users or distributions lists we just add the proper permissions to the mailbox and it is done.
First of all we need to create our Shared Mailbox and to do that we need to use the Exchange Management Shell!
[PS] C:\>New-Mailbox -Name "mailbox" -Database "database" -UserPrincipalName mailbox@domain.com -Shared
At this stage we have our mailbox created and our active directory user disabled...
However now we need to give the right permissions...
Let's start by giving instructions to the shared mailbox that a few users should have Full Access on it, otherwise won't work. Advice here is do this to a Security Group more than to individual users by the same reasons referred above. Let's do it then to the users on the Sales Team!
[PS] C:\>Add-MailboxPermission "mailbox" -User "user" -Access Rights FullAccess
Almost done but a couple more things to do. At this stage the users on the Sales Team can access totally the mailbox however they still can't send e-mails from the shared mailbox. To do that we need to give them some permissions in Active Directory side...
[PS] C:\>Add-ADPermission "mailbox" -User "user" -ExtendedRights Send-As
At this stage the Sales Users are GOD within the Sales Team Shared Mailbox.
With Exchange Server 2007 Service Pack 1 we can actually setup the Full Access and Send As permissions. Basically we just right click on the Shared Mailbox and add the recipients to the desired permission or just select the account, and on the right hand side of the console you will see the same options.
And that's it!
Posted by Pedro Alves
Exchange Recipients have changed a quite a bit since Exchange Server 2003. With this post I will try to give you an overview of how it works now and eventually a few tips regarding troubleshooting.
Recipient Management
One thing that definitely will make Exchange Administrators life easier is the Recipient Configuration container as it brings such a simplified recipient provisioning for them, such as the fact that we can split permissions in a single forest, or by other words we have the ability to delegate recipient management to a lower level Administrator as in we will not need to give unnecessary permissions to someone that should just deal with Recipients Management; other ability is we can now create Active Directory objects and mail or mailbox enable them without the need to use Active Directory Users and Computers.
We have improved a lot in terms of scoping as we can now choose between Domain or Forest scoping which basically will allow the Administrator to see only the objects relevant to him, and it can go down to a Organizational Unit level.
Finally seems that Exchange Server was the clear distinctions software starting on the server roles and yes, even here on Recipient Management. We now have very clear and distinct recipient types such as User Mailbox, Room Mailbox, Equipment Mailbox, Linked Mailbox and Shared Mailbox.
There is no longer a need to wait for a recipient to be populated or stamped from Recipient Update Service. Once a user is created from the Exchange Management Console or the Exchange Management Shell, the user is ready to go. If you use the Exchange Management Console for this task, the Edit Email Address Policy wizard will guide you through the process of editing and applying the policy. If you use the Exchange Management Shell, you will use the Set-EmailAddressPolicy cmdlet to edit the policy settings and the Update-EmailAddressPolicy to apply the policy to the intended recipients.
The policy is created with the mailbox now, and once it's created it takes effect immediately for users. For a recipient to receive or send email messages, the recipient must have an email address. Email Address Policies generate the primary and secondary email addresses for your recipients (which include users, contacts, and groups) so they can receive and send e-mail. By default, Microsoft Exchange contains an Email Address Policy that specifies the recipient's alias as the local part of the email address and uses the default accepted domain. The local part of an e-mail address is the name that appears before the at sign (@). For Email Address Policies, you define how the recipients' e-mail addresses will display. For example, you may want to have all of your e-mail addresses display as firstname.lastname@domain.com. In Exchange Server 2007, recipient policies (which were part of Exchange Server 2003) are divided into two separate features: accepted domains and email address policies.
Working With Recipients
In Exchange Server 2007, recipients are comprised of mailbox users, mail-enabled users, mail contacts, distribution groups, security groups, dynamic distribution groups and mail-enabled public folders. In previous versions of Exchange Server, you performed recipient management tasks in Active Directory Users and Computers. You can actually now create Active Directory user accounts from within the Exchange Management Console or Exchange Management Shell when these are mail or mailbox enabled. However, although you can perform all recipient management tasks in the Exchange Management Shell, only some are performed in the Exchange Management Console.
Working With Recipients And Active Directory Users And Computers
Have you ever asked yourself if having Exchange Server 2003 and Exchange Server 2007 in your Exchange Organization and using Active Directory Users and Computers extensions from Exchange Server 2003 to create a mailbox in an Exchange Server 2007 database, would work?
Answer is quite simple... or not. We do not have any way to block creating mailboxes on Exchange Server 2007 from Exchange Server 2007 Active Directory Users and Computers extensions, but it is not supported. There are negative consequences to doing this for the mailbox – principally that Exchange Server 2007 will see this mailbox as a “legacy” mailbox rather than a true Exchange Server 2007 mailbox and that will block various Exchange Server 2007 actions and properties from being edited.
To retrieve and fix all mailboxes wrongly set on the Exchange Server 2007 we need to run the Set-Mailbox -ApplyMandatoryProperties cmdlet. That parameter applies the mandatory properties to the "legacy" mailbox, such as version and type metadata associated with the mailbox. When you apply it a few steps happen:
The end result is that the mailbox will have its ExchangeVersion, RecipientTypeDetails, and RecipientDisplayType updated to match reality. When you create a mailbox through Exchange Server 2007 tools, all this process happens automatically. When you create an Exchange Server 2003 mailbox with Exchange Server 2003 tools and move it to Exchange Server 2007, it still happens automatically. However, if you create an Exchange Server 2007 mailbox using the Exchange Server 2003 Active Directory Users and Computers extensions, it will not happen automatically. Run this cmdlet against a mailbox where it's already been run will just reset the values to the same (correct, and presumably current) value, so no problem at all.
Scoping
The default scope for the admin session (whether in the Exchange Management Console or Exchange Management Shell) is what's called Domain Scope. This means that your admin session is configured to talk to a Domain Controller (not to the Global Catalog port, even if it's also a Global Catalog). And it means that your reads/writes will only operate within this Domain's Domain Controllers. This is pretty much how Active Directory Users and Computers snap-in handled scope too. Scope for the admin session only applies to first class objects. If I do Get-Mailbox cmdlet while I'm in Domain Scope, I'll only get back mailboxes (the first class object requested) for the current Domain Scope.
The Forest Scope is a little different. When you're in Forest Scope, the admin session talks to a Global Catalog for all reads (to get the whole Forest view), but does any writes back to a Domain Controller in the appropriate Domain. This is great because it means it's possible to get a view of all mailboxes in the whole Forest, for instance. But it's also bad, because when you're in this mode, replication latency can make things in your view be out of date - since you're reading from a Global Catalog and writing to a Domain Controller in the object's Domain, it's quite possible you won't read the latest data if it has just been changed. So, short version - Forest Scope is great because it lets you see a unified, Forest wide view. But beware of replication latency in some cases.
Administrators can control the scope of recipients shown to be the whole Forest, a whole Domain, or by Organizational Unit within a Domain by using the Modify Recipient Scope context menu of the Recipient Configuration node. Setting your scope controls which recipient objects will be displayed in the Graphic User Interface result panes and also controls which recipient objects will be found by the Graphical User Interface pickers in many cases. For instance, if you configure your scope to be a particular Organizational Unit, then you will only be able to specify this Organizational Unit or one of its children as the target of a new mailbox creation and you will only be able to select a user from this Organizational Unit or one of its children while enabling a mailbox. This can help to reduce the size of the result set you have to filter through while doing administrative tasks if your tasks are easily scoped to a particular part of the directory. In the Active Directory Users and Computers you see objects only under an Organizational Unit Scope, while Exchange Server 2007 Recipient Management allows you to define your scope to be an Organizational Unit, Domain, or even Forest wide increasing administrative flexibility.
$AdminSessionADSettings is a variable exposed by the Exchange Management Shell to allow you to control a number of aspects of the admin session:
The easiest way to manipulate this variable is just like you'd manipulate any other variable. Here's a syntax example:
[PS] C:\Documents and Settings\Administrator>$AdminSessionADSettings.ViewEntireForest = $true
[PS] C:\Documents and Settings\Administrator>$AdminSessionADSettings
ViewEntireForest: True DefaultScope: PreferredGlobalCatalog: ConfigurationDomainController: server1.domain.com PreferredDomainControllers: {}
Enable/Disable vs New/Remove
In Exchange Server 2007 each mailbox consists of an Active Directory user and the mailbox data that is stored in the Exchange mailbox database. All configuration data for a mailbox is stored in the Exchange attributes of the Active Directory user object. The mailbox database contains the mail data that is in the mailbox associated with the user account. Any of these operations can be done either on Exchange Management Console or Exchange Management Shell.
The Enable and Disable tasks are used against existing objects to remove attributes. When you enable, Enable-Mailbox, a mailbox you are adding Exchange attributes to an existent Active Directory object - mail or mailbox enable. When you disable, Disable-Mailbox, you remove those attributes leaving the mailbox orphan during the retention period after which it will be purged.
The New and Remove tasks need to have windows Account Operator permissions, otherwise the task will fail when trying to perform. Those tasks act directly on the Active Directory objects - mail or mailbox enable. When you create a mailbox, New-Mailbox, you will create a user on the Active Directory and respective mailbox if mailbox enabled or respective external SMTP address if mail enabled. When you remove a mailbox, Remove-Mailbox, you will be actually removing the Active Directory user and leave the mailbox orphan during the retention period, or you can actually through the Remove-Mailbox -Permanent cmdlet purge it with immediately effects. This last operation can only be done through Exchange Management Shell.
Last but not least we have the cmdlet Connect-Mailbox. Use it to connect a disconnected (disabled/removed) mailbox to an Active Directory object. Make sure that mailboxes have been used before at least once otherwise you will not see them here at all.
Email Address Policies
By default, Exchange contains an Email Address Policy for every mail or mailbox enabled user. This default policy specifies the recipient's alias as the local part of the email address and uses the default accepted domain. The local part of an e-mail address is the name that appears before the at sign (@). However you can change how your recipients' email addresses will display. For example, you can specify that your recipients' email addresses display as firstname.lastname@domain.com. Furthermore, if you want to specify additional email addresses for all recipients or just a subset, you can modify the default policy or create additional policies. In Exchange Server 2007, each time a recipient object is modified and saved, Exchange Server 2007 enforces the correct application of the email address criteria and settings. When an Email Address Policy is modified and saved, all associated recipients are updated with the change. In addition, if a recipient object is modified, that recipient's Email Address Policy membership is re-evaluated and enforced.
Exchange Server 2007 brings already some Pre-Canned filters to be used on the creation of Email Address Policies:
In addition Email Address Policies once created have to be applied to a set of users, but don’t have to be applied at that very moment. A schedule in the Exchange Management Console allows the Administrator to have the Email Address Policy to take effect after business hours. Exchange Server 2007 has eliminated the asynchronous behaviour of the Exchange Server 2003 Recipient Update Service in favour of a more predictable and synchronous provisioning process. Use the Update-AddressList and Update-EmailAddressPolicy Exchange Management Shell cmdlets. To replace the full functionality of Recipient Update Service, you can schedule these Exchange Management Shell cmdlets by using the Task Scheduler in Windows Server 2003.
Mailbox Manager functionality has been separated from Email Address Policies as in Recipient Policies used to be all in one. It has been replaced by Messaging Records Management functionality.
In continuation of my last post, Exchange Recipients, I brought this one to kind of complement a bit more and go deep on the troubleshoot side. Besides that will try to show differences or what we have new since Exchange Server 2003 to Exchange Server 2007.
Mailbox Management Tasks
We can split these ones between the functionalities that we brought from Exchange Server 2003 (even these ones having now Exchange Management Shell cmdlets) and the new ones that we got with Exchange Server 2007.
New Mailbox
With this one you can use the New Mailbox wizard in the Exchange Management Console or use the New-Mailbox Exchange Management Console cmdlet. To be able to create accounts you must be delegated Exchange Recipient Administrator role and Account Operator role for the applicable Active Directory containers. Administrators can create a new mailbox by creating a new user and mail or mailbox enabling it in one step, or by mail or mailbox enabling an existing user (in this last bit if using Exchange Management Console you use New Mailbox task, if using Exchange Management Shell you should use Enable-Mailbox cmdlet).
Move Mailbox
You can move mailboxes across mailbox databases, servers, domains, sites, and forests. You can also move mailboxes among different versions of Exchange Server 200x. To move mailboxes, you can use either the Move Mailbox wizard in the Exchange Management Console or use the Move-Mailbox Exchange Management Console command. To the specific scenario of moving mailboxes between forests you need to use the Exchange Management Shell.
Remove Mailbox
With this task the Exchange Management Shell cmdlet Remove-Mailbox will delete the user account (however if we use the Exchange Management Shell cmdlet Disable-Mailbox will remove the Exchange attributes between the user account and the mailbox - but at the end any of the cmdlets which can be performed through the Exchange Management Console too make the mailbox account orphan during the retention period, unless you use the Exchange Management cmdlet Remove-Mailbox -Permanent).
Change Mailbox
The properties of a mailbox can be modified from the Exchange Mailbox Console or using the Exchange Management Console cmdlet Set-Mailbox.
The new mailbox management tasks that we got with Exchange Server 2007 have a more statistical focus than the operational one found in the above tasks. These tasks can only be performed through Exchange Management Shell.
Get-LogonStatistics
With this task you can get the open item counts which tell us about the number of messaging operations, progress operations, table operations, transfer operations, total operations and successful Remote Procedure Calls operations. Besides that you can get the number of open attachments, folders and messages and names and identities associated with the database such as server, storage group, and full mailbox directory names. Last but not least you still can get other information such as latency, client version, client address and logon times.
Get-MailboxStatistics
This task can show you the size of the mailbox, number of messages it contains and last time it was accessed.
Get-MailboxFolderStatistics
Finally this one brings you information about the folders in a specified mailbox, including the number and size of items in the folder, the folder name and other information.
Mailbox Access Troubleshoot
We can troubleshoot a mailbox access issue in many ways, some of them known from the past, others not that much such as cmdlets from the Exchange Management Shell. Here are a few examples.
Test-MAPIConnectivity
This Exchange Management Shell cmdlet serves you basically to verify server functionality. It will log on to the mailbox that you specify (using the credentials of the account with which you are logged on to the local computer), or to the system mailbox if you do not specify the -Identity parameter, and retrieve a list of items in the Inbox. Logging on to the mailbox tests two critical protocols that are used when a client connects to a mailbox server: MAPI and LDAP. During authentication, the command indirectly verifies if the MAPI server, Exchange Store, and Directory Service Access are working. After a successful authentication, the command accesses the mailbox to verify that the database is working. If a successful connection to a mailbox is made, the command also determines the time that the logon attempt occurred. You have three levels of granularity here that it can be used through parameters: -Database: will take a database identity and tests the ability to log on to the system mailbox on the specified database; -Identity: will take a mailbox identity and tests the ability to log on to a specific mailbox; and finally -Server: which will take a server identity and tests the ability to log on to each system mailbox on the specified server.
Outlook Logging
Outlook logging can be enabled on the client side from the Outlook client or through the registry. By default the file is created in “\Documents and Settings\<username>\Local Settings\Temp”. The following article explains how to enable this logging: http://support.microsoft.com/kb/831053/en-us.
Network Trace
It is a good idea to reproduce the issue (try to logon from a local computer and see if the problem can be reproduced) while you monitor network traffic, on both the client and the server, at the same time. When you analyze the data, look for retransmits. A retransmit occurs when the client or the server has to send the same packet of information again, typically because the packets are being dropped between the client and the server. Therefore, when you analyze network captures, determine if the client request is actually getting to the server or if the server is responding but the response is lost before the client receives it.
Moving Mailbox
As said before, but it is always great to remember you can move mailboxes across mailbox databases, servers, domains, sites, and forests. You can also move mailboxes among different versions of Exchange Server 200x. To move mailboxes, you can use either the Move Mailbox wizard in the Exchange Management Console or use the Move-Mailbox Exchange Management Console command. To the specific scenario of moving mailboxes between forests you need to use the Exchange Management Shell.
One good thing that Exchange Server 2007 Move Mailbox task brings you is what is called the Pre Validation. Basically Move Mailbox task will perform a series of checks before actually trying to move the mailbox in a way it saves time by identifying errors right away, rather than waiting until they happen during the move process. Those tests will be user existence verification, source and target credential (done by connecting to the server), mailbox size limit against target database, system mailbox moves blocking, failure if source user does not have a mailbox and finally verification if the target mailbox is mounted.
Administrators can run the validation directly from the Exchange Management Shell cmdlet Move-Mailbox -ValidateOnly. In addition, validation is always executed before a “real” move, i.e. even when running moves using the Exchange Management Console Move Mailbox wizard, a Pre-Validation will be performed and any errors will be reported right away.
Some other advanced options you can use with this Exchange Management Shell cmdlet are:
Exchange Server 2007 Move Mailbox task improves on the existing Exchange Server 2003 logging functionality (event logs and XML report) and adds one new log feature, i.e. the troubleshooting log. All logs are enabled by default and are saved into this path: “<Exchange Install Root>\Logging\MigrationLogs\”.
Move Mailbox Troubleshoot
Email Address Enforcement
If you move a mailbox from Exchange Server 2003 or Exchange Server 2000 to Exchange Server 2007, and the mailbox is part of an e-mail address policy, the e-mail addresses for that mailbox will be automatically updated based on the configuration of the e-mail address policy. If the mailbox had a primary Simple Mail Transfer Protocol (SMTP) address that differs from the e-mail address enforced by the e-mail address policy, that SMTP address will become a secondary SMTP address and the e-mail address generated by the e-mail address policy will become the primary SMTP address. This behaviour is different from what used to happen before when mailboxes were moved to Exchange Server 2003 or Exchange Server 2000. In Exchange Server 2003 or Exchange Server 2000, the e-mail address policy is not applied to a mailbox when it is moved. To prevent accidentally changing the primary SMTP address of a mailbox in an Exchange Server 2007 environment, you must configure the mailbox so that is does not automatically update e-mail addresses based on e-mail address policy. To configure Exchange Server 2003 or Exchange Server 2000 mailboxes, in Active Directory Users and Computers, right-click the recipient, and then select Properties. On the E-mail Addresses tab, clear the Automatically update e-mail addresses based on e-mail address policy check box.
Move-Mailbox -IgnoreRuleLimitErrors
You can specify this parameter to avoid the Outlook 32 Kb rules limit. By default, the Move-Mailbox cmdlet will move rules, both in single forest and cross-forest moves. Using this Exchange Management Shell cmdle you will allow Exchange Server 2007 mailboxes that exceed this limit to be moved back to Exchange Server 2003 successfully. If this option is used the mailbox will be moved without rules.
Damaged or Corrupted Messages
If you are willing to lose the corrupted message, you can skip it when you rerun the Move Mailbox operation using the Exchange Management Console wizard or the Move-Mailbox cmdlet in Exchange Management Shell. In the Move Mailbox wizard, under Move options, you can decide to skip the corrupted message while with the Move-Mailbox cmdlet you can use the -BadItemLimit parameter. Other way of trying to troubleshoot this would be running the ISInteg to check for and fix the corrupted messages. A useful tip would be to you to verify if the antivirus software is not scanning the database where the mailbox you are trying to move at that moment is. Last but not least you can always use MFCMAPI to delete the corrupted message.
ExMerge Replacement
There are a few reasons we can point why is ExMerge not being shipped with Exchange Server 2007. Being separate code from the Exchange Server 2007 is one of them. One of the goals for Exchange Server 2007 is to reduce the number of separate tools and code bases supported for migration operations. ExMerge has always been completely separate from all shared Exchange migration code, as so this has caused several technical problems like the need to support an independent PST file provider and so on. These issues have caused delays in updates, limited functionality and extra support costs for customers and Microsoft as well. Besides that being an independent tool didn't help either. The fact that ExMerge is an independent tool has caused a lot of unintended consequences regarding the scenarios where it is used. Every time a tool is used for something it was not designed for, the risk of unintended consequences and bugs increase. Also, over use of the Exmerge tool works as an incentive to under use our other migration tools where they are better suited. This adds extra cost to the management of Exchange.
Obviously if we didn't ship ExMerge with Exchange Server 2007 we still needed to provide some replacement to our customers in the areas that out tools from previous versions of Exchange would not cover what ExMerge could cover. Regarding that the export and import PST files options in the Exchange Management Shell are another way in which we are investing in PowerShell as a scripting platform for Exchange Server 2007. The good news with the replacements is that Administrators can bypass Outlook when attempting to restore and backup a mailbox directly from a PST file and it will support Unicode PST files.
In practical terms those replacements, or in more appropriate words, those Exchange Management Shell cmdlets will be the following ones:
Export-Mailbox
Is a task developed by the migration team to allow Administrators to export content from active mailboxes to a folder inside other active mailboxes. The initial idea for this task was to be a complete replacement for ExMerge. The implementation of some of this functionalities was problematic and it required more time than initially planned. It deletes content from source mailbox after exporting it to target mailbox and also automatically exports dumpster items as regular messages in the target mailbox. Messages from the dumpster are converted to regular items in the folder or .pst file to which you export data. If you want to export from a PST file you need to run this cmdlet from a 32 bits box.
Import-Mailbox
To import data from a PST file to a mailbox, you need to run this cmdlet from a 32 bits box. You cannot import data by using the Import-Mailbox Exchange Management Shell cmdlet to a mailbox that is on a server running Exchange 2003 or Exchange 2000. To import data from a PST file to a mailbox on a server that is running Exchange 2003 or Exchange 2000, you must use the ExMerge tool. By default, the Import-Mailbox Exchange Management Shell cmdlet exports all empty folders, special folders, and subfolders to the target location. To specify folders to either include in, or exclude from the export, use the -IncludeFolders or -ExcludeFolders parameter. The Import-Mailbox cmdlet imports all associated folder messages if they exist in the PST file. Associated messages contain hidden data with information about rules, views, and forms. The Import-Mailbox cmdlet imports all message types, including messages, calendar items, contacts, distribution lists, journal entries, tasks, notes, and documents. When data is imported from a PST file, it is merged into the existing mailbox. If a message from the PST file already exists, it will not be imported as a duplicate message.
Restore-Mailbox
This Exchange Management Shell cmdlet is used to recover mailbox content from databases in the Recovery Storage Group. It ca only be used to copy data from a disconnected mailbox to an active one.
In this post I will try to bring you the way that all Recipient Lists, such as Address Lists or Distribution Lists behave in Exchange Server 2007 and what should we do with our old ones from Exchange Server 2003 and a few advices to some possible issues you may experience.
Distribution Lists Types
Most of the distribution lists types that you can get in Exchange Server 2007 are familiar if you have been dealing with Exchange Server 2003 as we can see below:
· Universal Distribution Group: This is the primary type of distribution group you will use for sending messages to large groups of recipients. You cannot assign permissions to this type of group.
· Universal Security Group: You can use this type of group to assign permissions to a group of recipients access permissions to resources in Active Directory and to send messages to all the recipients in the group.
· Non Universal Group: These are groups created in Exchange Server 2003. You will have limited access to them. You should change the scope of the group or create a new one with universal scope so they can become a universal group.
· Dynamic Distribution Group: This type of group doesn’t have a static list of recipients. It uses recipient filters to generate its membership when a message is sent to the group. Every time you will send a message to this group Exchange will query Active Directory. These groups are useful but should be used carefully. Every time a message is sent to these groups you should expect increased processor/disk/network activity.
Automatic Group Conversion
By definition, universal distribution groups and universal security groups are groups of recipients that are created to expedite the mass sending of e-mail messages and other information. However, unlike universal distribution groups, universal security groups can also be used to assign permissions. In Exchange, only the Active Directory objects that have security principals can be used to grant permission to a public folder or to a mailbox folder. However, it is possible for an Outlook user to use a universal distribution group to grant permission to a public folder or to a mailbox folder. In this case, the universal distribution group is automatically converted to a universal security group by the Information Store service. This is the default behaviour in Exchange Server 2007. This can potentially growth user security token.
It is possible to modify this behaviour to prevent the automatic conversion of universal distribution groups to universal security groups. The msExchDisableUDGConversion attribute of your Exchange Organization object in Active Directory is used to control how the Information Store service responds to requests for conversion of universal distribution groups to universal security groups. The following are the acceptable values for the msExchDisableUDGConversion attribute that you can edit on ADSIEdit tool:
Exchange Server 2003 Coexistence
The Dynamic Distribution Groups created in Exchange Server 2003 won’t be displayed in the management console. This is caused by the fact that in Exchange 2003 they use an LDAP filter while in Exchange Server 2007 they use an OPATH filter. In order to find which dynamic distribution groups needs an upgrade you may run the Exchange Management Shell cmdlet Get-DynamicDistributionGroup | Format-List Name,*RecipientFilter*,ExchangeVersion and look for these properties:
In order to solve this issue you have to set the RecipientFilter property by using the cmdlet Set-DynamicDistributionGroup –recipientfilter {... } –forceupgrade $true (the parameter –forceupgrade will disable the compatibility notification). After the upgrade you will be able to manage the Dynamic Distribution Groups using only the Exchange Management Console. Distribution Lists with Global or Domain Local scope cannot be created in Exchange Server 2007. Pre-existing mail-enabled non-universal groups will be kept but you will have limited management capabilities. Using mail-enabled non-universal distribution groups may lead to unpredictable membership expansion. This is due to the way group membership is replicated across Global Catalogs in multi-domain environments. In order to have full compatibility you should change the scope of the group or create a new one with universal scope.
Distribution Lists Common Issues
A couple of common issues that you may experience are, either you are unable to send an email to a distribution list if you are sending that from an external email address to your organization, or simply you can't see the distribution list at all using Exchange Management Console.
On the first issue, generally that behaviour occurs if you enable the option "Require that all senders are authenticated“ in the Distribution List properties on Mail Flow Settings on Message Delivery Restrictions. This flag will refuse all mails from non-authenticated users. This issue can be easily tested using a telnet session or Outlook Express to send a message using non-authenticated SMTP session. It can be solved from the Exchange Management Console as described above or through Exchange Management Shell cmdlet Set-DistributionList –RequireSenderAuthenticationEnabled $true.
On the second one this issue occurs if the group scope is Global or Domain Local. It can be easily checked using Active Directory Users and Computers. It can be solved by changing the group scope to Universal or by creating a new group with Universal scope.
Address Lists Types
An address list is a collection of recipients and other Active Directory objects. Each address list can contain one or more types of objects (e.g. users, contacts, groups, public folders, conference rooms and other resources). You can use address lists to organize recipients and resources, making it easier to find the recipients and resources you want. Address lists are updated dynamically. Therefore, when new recipients are added to your organization, they are automatically added to the appropriate address lists. Address lists reside in Active Directory, therefore, mobile users who are disconnected from the network are also disconnected from these server-side address lists, however, you can create Offline Address Books for users who are disconnected from the network. These can be downloaded to a user's hard disk drive. Frequently, to conserve resources, Offline Address Books are subsets of the information in the actual address lists that reside on your servers.
When users want to use their client application to find recipient information, they can select from available address lists. Several address lists, such as the Global Address List, are created by default. Exchange Server 2007 contains the following default address lists, which are then automatically populated with new users, contacts, groups, or rooms as they are added to your organization:
Populating Address Lists
Address lists are no longer dependent on the Recipient Update Service. In earlier versions of Exchange, the Recipient Update Service (a component within System Attendant service) updated the address lists and e-mail addresses in Active Directory. In Exchange Server 2007, changes to e-mail addresses and address lists are applied directly to Active Directory. As a result, when changes are made to address lists, you can immediately see the changes in Active Directory Users and Computers without having to wait for Recipient Update Service to perform the update. In Exchange Server 2003 and Exchange Server 2000, the graphical user interface for filtering address lists was complex, containing nested lists that had hundreds of properties. In Exchange Server 2007, the most common filters are defined as pre-canned filters, which contain a simple and intuitive filter control.
Besides the predefined ones there were some improvements on the customized ones too. For the few administrators that require advanced filtering requirements not met by pre-canned filters, you can create custom filters that can be defined by using the OPATH filter syntax in the Exchange Management Shell. OPATH is a querying language designed to query object data sources.
Exchange Server 2007 allows you to filter the results of a command by using the recipient type. For example, the Get-User, Get-Recipient, Get-Mailbox, Get-MailUser, Get-Contact, Get-MailContact, Get-Group, Get-DistributionGroup, and Get-DynamicDistributionGroup Exchange Management Shell cmdlets have a -Filter parameter with which you can specify the users or groups to retrieve with the command. When combined with the Set-AddressList or New-AddressList cmdlets, you can specify a set of users or groups to retrieve by using a filter string. This type of filter does not modify any configuration or attributes of objects. It only modifies the set of objects that the command returns.
As said before any change is applied directly and immediately, however if by any chance you want to do it off of labour hours Exchange Server 2007 has the ability to schedule the application of address lists at a later time. You can specify when changes to the address list should be applied. You can also specify the amount of time that the tasks should run. If you prefer to do it using Exchange Management Shell you can use the Update-AddressList cmdlet to schedule or simply apply it with immediate effects.
Address Lists Common Issues
A couple of common issues that you may experience are, either you are unable to edit an address list properties, or changes you have done on an address list don't show up when you see them.
On the first issue if address lists have been created using Exchange Server 2003 they must be upgraded in order to be able to modify them using Exchange Management Console. This is due to the fact that Exchange Server 2007 uses OPATH filters based on the Exchange Management Shell instead of using LDAP filters as in Exchange Server 2003. In order to have a list of the address lists which should be upgraded you may use Get-AddressList | Format-List Name,*RecipientFilter*,ExchangeVersion or Get-GlobalAddressList | Format-List Name,*RecipientFilter*,ExchangeVersion Exchange Management Shell cmdlets. If one of the below conditions occurs you will have to upgrade the Address Lists:
At least three of the basic Address Lists can be corrected using pre-canned filters:
Others may need custom filters (Public Folders and Global Address List)
On the second issue since Exchange Server 2007 has no Recipient Update Service, the address lists must be manually updated if you experience the described issue, using Exchange Management Console or the Exchange Management Shell cmdlet Update-AddressList. If that still doesn't work and in order to troubleshoot issues related to the Recipient Update Service API you may enable diagnostic logging of the Recipient Update Service API using the cmdlets Get-EventLogLevel MSExchangeAL and Set-EventLogLevel.
I've been spending quite a lot of time looking at mail routing options using a shared namespace - not something most people tend to do, however quite important in this case J
I found some information at MSExchange.org that helps clarify the routing mechanism that takes place in Exchange 2007, and when to use the different types of relay options available.
In this case we wanted to be able to route mail from a hosted service to an IMAP-based platform while in co-existence mode. This would use the "mailhost" attribute in the local directory to re-route the message to AD, and the Hub Transport servers would then route the message to the local message stores. Effectively users who have not been migrated yet would be in the AD as mail-enabled users, but with the "TargetAddress" set to match the SMTP address - this fools the server into thinking that the user is in fact, a contact! The message would then be routed via relay to the IMAP servers, therefore preventing the need to create contact placeholders for the users prior to migration. It also means that changing from a contact to a mail-enabled user is a far less exhauting task...
I also managed to dig out some information on categorisation, which can be found here.
There's a very good TechNet article available that describes the steps that are required in order to fail over from a CCR cluster in one site, to an SCR target in another site. It also covers the procedure to fail back once the problem has been resolved.
Standby Continuous Replication: Site Resilience with Standby Clusteringhttp://technet.microsoft.com/en-us/library/bb738150(EXCHG.80).aspx
This event will be held in London at the MSFT offices in Cardinal Place near Victoria.
This month we have a topical session led by Clive Watson, Brett Johnson and Julius Davies from Microsoft. We will be discussing the new support statements surround the issue of virtualising your Exchange environment. Having understood which pieces of Exchange are now supported we will look at some of the key design issues facing those virtualising Exchange.
The meeting will be held on Tuesday 11th November and starts at 18:30.
For more information and to sign up please see the link below:
http://www.mmmug.co.uk/forums/thread/23926.aspx