Microsoft UK UC Blog

Automating Jetstress…

One of the things I like about Jetstress is that it tends to identify failing or failed components before the servers go live.  Its not all about how many IOPS a storage array can provide, sometimes its just as important to prove the stability of the infrastructure and not just its peak performance.

So, we all know that Jetstress is a great tool.  It helps us prove our storage design and is also really good for finding problems in a storage deployment before it goes live.  The problem is that it takes a while to initialize and run – and quite often on a large project different people will configure the test slightly differently, even with clear documentation.

On my current project I was faced with the requirement of deploying and therefore jetstress testing,  20 CCR clusters, which meant 40 jetstress tests!.  Along with all of the other deployment “stuff” this wasn't going to leave me with much time…. not to mention that setting up jetstress and watching it run for a few hours is like watching paint dry…

This is where I decided I would look at automating the jetstress process from end to end.  I already had a pretty solid automated build process (I will blog about this in the next few weeks), so I just needed to tag in the jetstress bits prior to installing Exchange and I would be all set…

Jetstress process outline

Before I could begin automating things I needed to determine exactly what I needed to automate…

1. Create Jetstress directories
2. Install Jetstress
3. Copy over ESE DLL files
4. Start Jetstress to register the DLL files
5. Close Jetstress
6. Start Jetstress Again
7. Configure test
8. Initialize databases
9. Run Test
10. Copy output files centrally
11. Remove test databases
12. Uninstall jetstress

Pre-Requisites

In addition to the actual functions, I also had some pre-requisites…

1. Disks need to be ready
2. Need to have a copy of the intended ESE Dll’s
3. Need to have exported the Jetstress XML config file from the GUI
4. Must have powershell installed

Phase 1 (Steps 1 – 3)

The first phase is where we create the directory structure, install jetstress and copy over the ESE dll files we need to use.

Step 1 – Create Jetstress directories

To do this I decided to use powershell.  To make things really easy I wrote some code to query the jetstress xml file and look at the directories specified within it.  This would allow me to use the process with any jetstress configuration file without needing to update any code.  Copy the following lines of code and save it as create_jetstress_dirs.ps1

create_jetstress_dirs.ps1

###### BEGIN COPY UNDERNEATH THIS LINE ############

Step 2 – Install Jetstress

Jetstress supports silent installation, so installing it is as simple as running the following command from a batch file or powershell script…

Step 3 – Copy over ESE DLL files

Jetstress simply uses the Exchange ESE dll files to create and control the databases for testing.  As such it requires a copy of the ESE dll files before it can begin.  The following files are required for jetstress to function…

• ese.dll
• eseperf.dll
• eseperf.hxx
• eseperf.ini

I recommend copying these files from a production server that will be running the same version of Exchange into a directory you can keep for later use.

Now we have our ESE DLL files and a copy of jetstress installed, we just need to copy them into the jetstress installation directory…

xcopy C:\JetStress\ESE\SP1-RU5-x64\*.* "C:\Program Files\Exchange Jetstress" /y

So, with phase 1 complete, we have a batch file that looks like this…

@echo off
set configfile=c:\jetstress\jetstress.xml
cd c:\jetstress
powershell -file c:\jetstress\create_jetstress_dirs.ps1 %configfile%
start /wait msiexec /i c:\jetstress\jetstress.msi /quiet
xcopy C:\JetStress\ESE\SP1-RU5-x64\*.* "C:\Program Files\Exchange Jetstress" /y

Phase 2 - (Steps 4 - 9)

So this bit took me quite a while to get working exactly as I wanted.  Essentially on first run JetStress will register the ESE files and performance counters with the operating system.  If you are doing this via the GUI, it simply asks you to close and re-open JetStress after it has registered the DLL files.  In the command line things are more complicated…

By default when you run JetStressCmd.exe it will register the DLL files and then spawn off a second copy of the process in a new window.  This upsets the natural flow of my batch file because essentially the original JetStress process has now terminated so the batch file continues and in my case reboots! – I needed to run JetStress then carry on and do other things.  The way I got around this behaviour was to initially begin JetStress with the /? switch – this forces the registration of the DLL files, but allows my batch file to continue as expected…

So, our batch file now looks like this…

Phase 3 - (Steps 10 - 12)

So, after roughly 4 hours we have completed our JetStress test – the next step is to copy the results and logs into a directory we can harvest later on.  For my deployment I chose c:\jetstress\jetstress_results – however given sufficient permissions you could choose to directly copy the results to a shared location on a server somewhere.  With hindsight this is the route I should have chosen for this deployment and I will aim to do this for the next one.

We are ideally looking to retain copies of the HTML, BLG, LOG and XML files that exist within the JetStress installation directory.  Assuming you have installed into the default directory  the following lines of batch file will gather the results…

mkdir c:\jetstress\jetstress_results
xcopy "c:\program files\exchange JetStress\*.html" c:\jetstress\jetstress_results\ /y
xcopy "c:\program files\exchange JetStress\*.blg" c:\jetstress\jetstress_results\ /y
xcopy "c:\program files\exchange JetStress\*.log" c:\jetstress\jetstress_results\ /y
xcopy "c:\program files\exchange JetStress\*.xml" c:\jetstress\jetstress_results\ /y

The next step is to uninstall JetStress from the server ready for its Exchange installation.  The following lines of batch file will uninstall JetStress and remove any files that are left in that directory…

start /wait msiexec /uninstall c:\jetstress\jetstress.msi /quiet
cd c:\jetstress
rmdir "C:\Program Files\Exchange Jetstress" /Q /S

The next thing left to do is remove the JetStress test databases and directories.  For that we will use a slightly modified version of our earlier powershell script.

remove_jetstress_dirs.ps1

###### BEGIN COPY UNDERNEATH THIS LINE ############

###### BEGIN COPY ABOVE THIS LINE ############

After this point we have completed our jetstress test and we are ready to move on.  I simply saved this batch file as c:\jetstress\runjetstress.cmd and called it from powershell at the point in my automated build where I wanted to run it.

So our final automated jetstress batch file looks like this…

@echo off
set configfile=c:\jetstress\jetstress.xml
cd c:\jetstress
powershell -file c:\jetstress\create_jetstress_dirs.ps1 %configfile%
start /wait msiexec /i c:\jetstress\jetstress.msi /quiet
xcopy C:\JetStress\ESE\SP1-RU5-x64\*.* "C:\Program Files\Exchange Jetstress" /y
cd "C:\Program Files\Exchange Jetstress" 
JetStressCmd.exe /? 
JetstressCmd.exe /c %configfile% /timeout 2H0M0S /new
mkdir c:\jetstress\jetstress_results
xcopy "c:\program files\exchange JetStress\*.html" c:\jetstress\jetstress_results\ /y
xcopy "c:\program files\exchange JetStress\*.blg" c:\jetstress\jetstress_results\ /y
xcopy "c:\program files\exchange JetStress\*.log" c:\jetstress\jetstress_results\ /y
xcopy "c:\program files\exchange JetStress\*.xml" c:\jetstress\jetstress_results\ /y
start /wait msiexec /uninstall c:\jetstress\jetstress.msi /quiet
cd c:\jetstress
rmdir "C:\Program Files\Exchange Jetstress" /Q /S
powershell -file c:\jetstress\remove_jetstress_dirs.ps1 %configfile% 

So, there you have it – a totally automated and predictable method of running JetStress on your production servers.  So far I have been using this process for the last six months and it has proven to be incredibly robust.

One last thing, I also chose to parse the results HTML file to attempt to determine if the test had passed or failed.  The following powershell shows how I did this…

Posted by Neil Johnson, MCS UK, MCM Exchange 2007

Updated Combined Role HUB/CAS Scaling Guidance…

Well, its been a long time in the making and I for one have been waiting for a long time for this data to be published publically.  I was fortunate enough to be taught by Bill Thompson at the ECoE during my Masters rotation and he went through some of the data in this paper.  It dramatically altered the way I approached HUB/CAS scaling work…

If you are currently designing Exchange 2007 or planning to, I highly recommend you read through this paper.

http://technet.microsoft.com/en-us/library/dd901772.aspx

Posted by Neil Johnson, MCS UK, MCM Exchange 2007

Reverse Number Lookup and Dealing with Legacy PBX

Working with customers I have come across a number of scenarios where the caller ID presented from the PBX is not in E164/DID (Direct Inward Dial) format. Some gateways allow for extensive manipulation of the caller ID, some less so. The good news is that in OCS 2007 R2 you can now easily solve the problem and this has also been made available as a hotfix for OCS 2007 R1 (http://support.microsoft.com/kb/954647/en-us) . Below is an explanation of how it works and what you need to put in place.

In a simple scenario, you have 2 sites, each with a PBX. There is in place standard short code site dialing. I have also included the PBX node numbers as I have seen these exposed in some cases.

Now if we take the simple scenario of Peter in Reading on OCS which is connected through a mediation server and a basic gateway to a PBX in Reading. Joe is a user in London connected to a PBX in London.

When Joe calls Peter the following occurs

The call is routed from the London PBX to the Reading PBX and then on to the basic gateway.

The gateway will create a SIP invite message and the “to” address is usually formatted correctly but the “from” address could be in one of several formats depending on your legacy PBX

DID number 442031391212

Short Dial number 8021212

Internal dial number 84041212

If you are fortunate and it is in DID format then the basic gateway can easily add +, as can the mediation server. More likely though you either have the short dial number, or as in this case the internal dial number (using the PBX node number)

You can see from the log from my basic gateway the formatting of the different addresses I have highlighted in red.

---- Outgoing SIP Message to 10.1.10.7:5060 ----

INVITE sip:+441189093291@10.1.10.7;user=phone SIP/2.0

Via: SIP/2.0/TCP 10.1.10.10;branch=z9hG4bKac295994674;alias

Max-Forwards: 70

From: "84041212" <sip:84041212@10.1.10.10>;tag=1c295989178

To: <sip:+441189093291@10.1.10.7;user=phone>

Call-ID: 29598879711200021026@10.1.10.10

CSeq: 1 INVITE

Contact: <sip:84041212@10.1.10.10;transport=tcp>

Supported: em,100rel,timer,replaces,path,resource-priority

Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE

User-Agent: Audiocodes-Sip-Gateway-MP-114 FXS_FXO/v.5.00A.035.003

Content-Type: application/sdp

Content-Length: 258

When the message is received by the mediation server, because the “from” number is not in E164 format it will add its configured location profile to the “from” address as a phone-context which I have highlighted in red in the log below.

TL_INFO(TF_PROTOCOL) [0]0B9C.1004::03/18/2009-13:48:03.831.000010a9 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record

Instance-Id: 00000134

Direction: incoming

Peer: redmed01.europe.corp.microsoft.com:2503

Message-Type: request

Start-Line: INVITE sip:peter@microsoft.com;opaque=user:epid:jDT7sohH91mi5ocvidTJugAA;gruu SIP/2.0

From: <sip:84041212;phone-context=readingmediationserver@microsoft.com;user=phone>;epid=1460650F33;tag=dedea5f4a2

To: <sip:+441189093291@microsoft.com;user=phone>;epid=7e731b1d1b;tag=03d30514a1

CSeq: 16 INVITE

Call-ID: b7a0659b-57d0-4336-98e8-0725f897415b

MAX-FORWARDS: 70

VIA: SIP/2.0/TLS 10.1.1.7:2503;branch=z9hG4bK42fecdc

ROUTE: <sip:redmed01.europe.corp.microsoft.com:5061;transport=tls;opaque=state:T;lr>

CONTACT: <sip: redmed01.europe.corp.microsoft.com @microsoft.com;gruu;opaque=srvr:MediationServer:kqKefwcAxUeuOkjBv6DxWwAA;grid=92401592ca3b413db9bf01d752fdbf7b>;isGateway

CONTENT-LENGTH: 704

SUPPORTED: replaces

SUPPORTED: ms-safe-transfer

SUPPORTED: gruu-10

SUPPORTED: 100rel

USER-AGENT: RTCC/3.5.0.0 MediationServer

CONTENT-TYPE: application/sdp

Message-Body: v=0

The pool front end server uses the location profile in the phone-context to normalise the number. I would recommend using a different location profile to the one you assign to users as the rules can be slightly different and allows you the flexibility to customise it to your PBX.

It adds a “P-Asserted-Identity” field to the invite message with the normalised number as shown towards the bottom of the invite message below.

TL_INFO(TF_PROTOCOL) [0]0B9C.1004::03/18/2009-13:47:56.380.00000f6e (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record

Instance-Id: 00000124

Direction: outgoing

Peer: 10.1.1.1:3121

Message-Type: request

Start-Line: INVITE sip:10.1.1.1:3121;transport=tls;ms-opaque=29e2f0e8e5;ms-received-cid=800 SIP/2.0

From: <sip:84041212;phone-context=readingmediationserver@microsoft.com;user=phone>;epid=1460650F33;tag=dedea5f4a2

To: <sip:+441189093291@microsoft.com;user=phone>;epid=7e731b1d1b

CSeq: 14 INVITE

Call-ID: b7a0659b-57d0-4336-98e8-0725f897415b

Record-Route:<sip:redmed01.europe.corp.microsoft.com:5061;transport=tls;opaque=state:F:Ci.R800:Ieh.F3iAkjnCzw86ws8Paad7Q-xhoz-dlzMeAcTz0kz9ap5Qzj4gqUobs-iQAA;lr;ms-route-sig=aayPE3zUoe-C6QGmGlfPRG4c_CpiLj4gqUobs-iQAA>;tag=5394737F5C726A52BF0897201BE0E06B

Via: SIP/2.0/TLS 10.1.1.2:5061;branch=z9hG4bK494BEF08.940AE2E3D46C2B3C;branched=TRUE;ms-internal-info="aaJ40wWI6TcWSrM9kHR3RfmIeBWPvj4gqUlmojpgAA"

Proxy-Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFF4B108BAF713F56BEA6F3CC8B197124B2", srand="F46844E8", snum="51", opaque="30115551", qop="auth", targetname="sip/dubocs01.europe.corp.microsoft.com", realm="SIP Communications Service"

Max-Forwards: 69

Content-Length: 2492

Via: SIP/2.0/TLS 10.1.1.7:2503;branch=z9hG4bKdb55b847;ms-received-port=2503;ms-received-cid=E00

Contact: <sip: redmed01.europe.corp.microsoft.com @microsoft.com;gruu;opaque=srvr:MediationServer:kqKefwcAxUeuOkjBv6DxWwAA;grid=92401592ca3b413db9bf01d752fdbf7b>;isGateway

Supported: replaces

Supported: ms-safe-transfer

Supported: gruu-10

Supported: 100rel

User-Agent: RTCC/3.5.0.0 MediationServer

Content-Type: multipart/alternative; boundary=uuXBWe9zTOKnsjncYiXRaSzuM0iotixl

Allow: UPDATE

Allow: Ack, Cancel, Bye,Invite,Refer

P-Asserted-Identity: <sip:+442031391212@microsoft.com;user=phone>

History-Info: <sip:peter@microsoft.com>;index=1

Message-Body: --uuXBWe9zTOKnsjncYiXRaSzuM0iotixl

When the invite message is received by the Office Communicator client it uses either the “From” field or the “P-Asserted-Identity” field to match against the address book and local Outlook contacts. The problem here is that the numbers in the address book come from Active Directory and these are usually in the short dial format as they are used by users who are not using OCS enterprise voice.

e.g.

For this you need to amend the company normalization rules file (Company_Phone_Number_Normalization_Rules.txt) so that it generates number that can be matched against. In this example for London you would add

##

# 802xxxx +44203139xxxx London

##

802[\s()\-\./]*(\d\d\d\d)

+44203139$1

I would also recommend you add a test input entry

#TestInput: 8021234 TestResult: +442031391234

This enables you to easily test your address book normalization rules using the command line:

Abserver.exe -testPhoneNorm

Which would give output like the following:-

Running 1 normalization rules tests

Test from Company_Phone_Number_Normalization_Rules.txt on line 37

Input: '8021234'

Expected Result: '+442031391234'

Actual Result: '+442031391234'

Test PASSED

Matching Rule in Company_Phone_Number_Normalization_Rules.txt on line 15

^802[\s()\-\./]*(\d\d\d\d)$

You can also output the Address book to a text file to view how your numbers are normalizing e.g.

Abserver.exe /dumpFile “f-0bb5.dabs” c:\absdump.txt

Where f-0bb5.dabs is the latest full address book file. You will see entries similar to the following:-

ContactId {GUID}

Mail joe@microsoft.com

TelephoneNumber 802 1212

TelephoneNumber tel:+442031391212

msRTCSIPPrimaryUserAddress sip:joe@microsoft.com

displayName Joe Bloggs

Sn Bloggs

givenName Joe

Notice that there is an additional telephone number entry with the normalised version of the number. This is the normal telephone number field in Active Directory, not the SIP Line URI.

Summary

To summarise what you need to do is:

· Create location profile for mediation server

· Have a consistent number format for telephone numbers in Active Directory

· Edit Company_Phone_Number_Normalization_Rules.txt file to normalize numbers from Active Directory for the address book.

Posted by Paul Brombley

Updated : Exchange version powershell script

Further to my blog post on April 30th, I have updated the powershell script to output in a more usable manner and also detect more information about your exchange servers…

Powershell Code…

Posted by Neil Johnson, MCS UK, MCM Exchange 2007

Microsoft Certified Master : Exchange 2007 - A survivors guide…

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…

• Microsoft Certified Master: Microsoft Exchange Server 2007
• Microsoft Certified Master: Microsoft SQL Server 2008
• Microsoft Certified Master: Windows Server 2008: Directory
• Microsoft Certified Master: Microsoft Office SharePoint Server 2007
• Microsoft Certified Master: Microsoft Office Communications Server 2007

What to expect?

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 :)

Preparation

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…

• Microsoft Virtual Server
• VMRCplus
• ISA

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!)

Accommodation

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 :)

Dealing with Jetlag

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

Socialising

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.

Health and Welfare

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!

Exams

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 :)

Qualification Lab

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.

Other Stuff and DSN

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… :)

Are you ready?

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…

• Official MCM Exchange 2007 Page
• The Master Blog

PS.  The pictures were all expertly taken by Morten Kjønnø

Posted by Neil Johnson, MCS UK, MCM Exchange 2007

How to retrieve the store.exe version from all mailbox and clustered servers in one step!?

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…

Posted by Neil Johnson, MCS UK, MCM Exchange 2007

Is your E2K7 project in danger of being scrapped?

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

Shared Mailboxes

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

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:

1. Check whether the mailbox is hosted on Exchange Server 2007 by verifying its ServerLegacyDN (by the prefix “/o=<OrganizationName>/ou=<DefaultAdministrativeGroupName>/”);
2. If it is, we do both of the following things: the ExchangeVersion value is changed to Exchange Server 2007, "0.1 (8.0.535.0)"; the RecipientTypeDetails/RecipientDisplayType is updated according the value of “IsResource/IsLinked/IsShared”;
3. Otherwise, we error out to tell that the task cannot do it because it is hosted on legacy server;

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:

1. ViewEntireForest is a Boolean (set with $true or $false) that controls whether we're in Forest Scope ($true) or Domain Scope ($false);
2. DefaultScope is the path you're scoped to (i.e. domain.com, domain.com/users, domain.com/users/department). It's ignored if you're in Forest Scope;
3. PreferredGlobalCatalog is how you can hardcode a Global Catalog server to be used for anything that requires it (Forest Scope, and also doing resolution of any global objects you're referencing in the admin session);
4. ConfigurationDomainController is how you can hardcode a configuration Domain Controller;
5. PreferredDomainControllers is how you can configure one (or more) Domain Controllers to be used by the admin session any time as it is required (Domain Scope, or writes while in Forest Scope). This is a multi-valued entry, so you can add more than one. If you need a Domain Controller for a Domain where there isn't Domain Controllers specified here, Active Directory Driver will go find one automatically and ignore this list;

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:

• State or Province - Select this check box if you want the Email Address Policy to only include recipients from specific states or provinces. This information is contained on the Address and Phone tab in the recipient's properties;
• Department - Select this check box if you want the Email Address Policy to include only recipients in specific departments. This information is contained on the Organization tab in the recipient's properties;
• Company - Select this check box if you want the Email Address Policy to include only recipients in specific companies. This information is contained on the Organization tab in the recipient's properties.
• Custom - Select this check box if you want the Email Address Policy to include only recipients in specific customized fields you have defined in your users' information. This information is contained on the Organization tab in the recipient's properties. This information will be visible on the Exchange Management Console, however to be edited you need to use Exchange Management Shell.

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.

Posted by Pedro Alves

Mailbox Management

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:

• -GlobalCatalog: Sets Global Catalog to be used during migration;
• -DomainController: Sets Domain Catalog to be used during migration;
• -MaxThreads: Number of mailboxes to be moved simultaneously (default is four);
• -ValidateOnly: Only runs validation code as so mailbox is not moved;
• -ReportFile: Used for changing the directory and/or file name for the XML report;
• -IgnoreRuleLimitErrors: Used for migrations from Exchange Server 2007 to Exchange Server 2003. This relates to the 32 Kb limit for rules in Exchange Server 2003, allowing 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.

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\”.

• Event Logs - Besides logging start and end of migrations, we now log all errors, warnings and any change to Active Directory objects, such as deleting source mailboxes for cross organization moves and we also use a more intuitive category name, i.e. "Move Mailbox“.
• Move Mailbox XML Report - This report now provides a lot more information than before, such as Source and Target Global Catalog and Domain Controller, all options used, total of mailboxes moved (including total of warnings and errors), more data about the mailbox being moved (size, primary SMTP, DN, LegacyExchangeDN, identity) and start and end time both for individual moves and for the overall move action for multiple mailboxes. Administrators can also choose a specific directory and file name for this report by using the parameter -ReportFile. If -ReportFile is not defined, the log will be created in the default location and called move-MailboxHHMMSS.xml.
• Troubleshooting Log - This is a new log for Exchange Server 2007 that displays detailed information about the move which can help in diagnosing move failures. It contains all the information of the other logs with additional detail like Active Directory search operations, user matching details, delegation processing, etc. This log will be created as move-MailboxHHMMSS.log.

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.

Posted by Pedro Alves

Recipients List

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:

• 0: Universal distribution groups are automatically converted to universal security groups when they are used to grant permissions to public folders or mailbox folders.
• 1: Outlook cannot request the conversion. However, Exchange system processes can still convert a universal distribution group to a universal security group (e.g. Exchange upgrade).
• 2: Automatic conversions do not occur.

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:

• LDAPRecipientFilter: Populated but RecipientFilter is empty (Exchange Server 2003 doesn't populate RecipientFilter);
• RecipientFilterType: Legacy;
• ExchangeVersion: 0.0 (6.5.6500.0)

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:

• Global Address List: This address list contains all recipients in the organization. During setup, Exchange creates various default address lists. The most familiar address list is the Global Address List. By default, the it contains all recipients in an Exchange Organization. In other words, any mailbox-enabled or mail-enabled object in an Active Directory forest that has Exchange installed is listed here. For ease of use, it is organized by name, not by e-mail address.
• All Contacts: This address list contains all contacts in your organization. Contacts are those recipients who have an external -mail address. If you want a contact information to be available to all users in your organization, you must include the contact in the GAL.
• All Groups: This address list contains all mail-enabled groups in your organization. Mail-enabled groups are a group of recipients that are created to expedite the mass e-mailing of messages and other information. When an e-mail message is sent to a mail-enabled group all members of that list receive a copy of the message.
• All Rooms: This address list contains all resources that have been designated as a room in your organization. Rooms are resources in your organization that can be scheduled by sending a meeting request from a client application. The user account that is associated with a room is disabled.
• All Users: This address list contains all mail and mailbox-enabled users in your organization including equipment mailboxes. A mail-enabled user represents a user outside your Exchange Organization with an external e-mail address. All messages sent to mail-enabled users are routed to this external e-mail address. A mail-enabled user is similar to a contact, except that a mail-enabled user has Active Directory logon credentials and can access resources. A mailbox-enabled user as referred before has a mailbox on your Exchange Organization and obviously Active Directory credentials. Last but not least Equipment Mailboxes work as Rooms but are more related to video or audio equipment you may want to reserver, and so these ones have a disabled Active Directory user.
• Public Folders: This address list contains all mail-enabled public folders in your organization. Access permissions determine who can view and use the folders. Public folders are stored on computers running Exchange.

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:

• LDAPRecipientFilter: Populated but RecipientFilter is empty (Exchange Server 2003 doesn't populate RecipientFilter);
• RecipientFilterType: Legacy;
• ExchangeVersion: 0.0 (6.5.6500.0)

At least three of the basic Address Lists can be corrected using pre-canned filters:

• Set-AddressList "All Users" -IncludedRecipients MailboxUsers
• Set-AddressList "All Groups" -IncludedRecipients MailGroups
• Set-AddressList "All Contacts" -IncludedRecipients MailContacts

Others may need custom filters (Public Folders and Global Address List)

• Set-AddressList "Public Folders" -RecipientFilter { RecipientType -eq 'PublicFolder' }
• Set-GlobalAddressList "Default Global Address List" -RecipientFilter {(Alias -ne $null -and (ObjectClass -eq 'user' -or ObjectClass -eq 'contact' -or ObjectClass -eq 'msExchSystemMailbox' -or ObjectClass -eq 'msExchDynamicDistributionList' -or ObjectClass -eq 'group' -or ObjectClass -eq 'publicFolder'))}

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.

Posted by Pedro Alves

Mail routing with a single namespace during migration co-existence

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.

Step by step guide on failing over from CCR to SCR

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 Clustering
http://technet.microsoft.com/en-us/library/bb738150(EXCHG.80).aspx

 

Posted by Chris Stevenson

November MMMUG in London

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

MCSTalks Today - Security and PKI

Don't forget to attend the next in the UK MCSTalks series.  Today's topic is 'Security and PKI'..

For details of how to register to listen in go to the 'MCS Talks' blog at; http://blogs.technet.com/mcstalks/default.aspx 

This is a list of the sessions:

The sessions are recorded and are available for download on the blog.  Any questions taken during the sessions are also posted.  If you do listen in and have any comments or feedback please let us know...