New hires at Microsoft get a couple of months of so called "Ramp up". This is the time you are given, as a new hire, to up your knowledge and get everything sorted that you need so that you can start doing customer deliveries! You still have the chance to take workshops, training sessions and bootcamps throughout the year (ofcourse :) ) but this is the only time where you don't have to worry too much about customers, utilisation and the likes.
Unfortunately ramp up is over for me :(! Don't get me wrong, I love our customers and working with them but having a number of months dedicated to nothing but training is amazing and still makes my head spin! I still have a huge wishlist of training sessions, accreditations and certifications I want to get (and have approval from my manager :D) so I'll still be busy for a while! Not too sure if I will be able to get any technical articles up in between training and customer engagements, but who knows. I might catch a lucky break :)
As an MSFT I have the ability to start up a Technet blog, which I gladly take. I will continue to write and post articles here as my "personal" blog store and will share the technical articles on both sites!
http://blogs.technet.com/b/messaging_and_beyond/
In the case you find yourself with a broken server and no
way of recovering it, the recovery install in Exchange 2007 and 2010 might just
be a way to avoid messing around with system repair or even system state
recoveries. This option actually allows you to remove this kind of backup
strategy all together! Why you might ask, well, simply put, starting from Exchange
2007 all configuration data is stored in the active directory, more
specifically in the configuration partition of the active directory:
CN=ExServerName,CN=Servers,CN=First Administrative
Group,CN=Administrative Groups,CN=ExOrg Name,CN=Microsoft Exchange, CN=Services,
CN=Configuration, DC=DomainName,CN=Com
Let’s have a closer look at this shall we?
- Open
adsiedit.msc
- Right
click and slect “connect to”
- Under
select a well know naming context select the configuration from the dropdown
- Drill
down configuration, services, Microsoft Exchange, the name of your
organisation, administrative groups, Exchange administrative group, servers
- Right
click one of the server objects in this field
- Scroll
down until you see the msExchCurrentServerRoles
In my case the number here is 38. What this number
represents is the sum of which roles have been installed! Each role has its own
value and Exchange knows what kind of roles need to be installed if you perform
a recovery installation. Pretty neat isn’t it?
|
Server
Role
|
msExchangeCurrentServerRoles
value
|
|
Mailbox Server
|
2
|
|
Client Access Server
|
4
|
|
Unified Messaging Server
|
16
|
|
Hub Transport Server
|
32
|
|
Edge Server
|
64
|
So, in case you want to perform a recovery server install
you can do the following:
- Install your base operating system with the same
name as the server you want to install
- Setup any required prerequisites
- Start the Exchange setup as follows:
- Setup
/m:recoverserver
- Wait for setup to complete
- Restore any databases if required.
If you take a minute to scroll through these attributes in
the properties of the server object you see that there are A LOT of
configuration settings stored here! For example there is msexchinstallpath
which contains the installation path for Exchange,
msExchCustomerFeedbackEnabled to see whether or not Exchange will send back
feedback to Microsoft, msExchELCAuditLogPath for the auditing logs and many,
many more!
In the lifespan of an organisation its messaging environment
be transitioned to a newer version several times. Whilst this is not a
complicated thing to do it does require some level of planning and thought.
I’ll be addressing the transitioning from Exchange 2007 to 2010 from a fairly
simple view here. Since the general outlines of the process are the same for
nearly every situation there is no need for different detailed documents on
this.
We’ll be working with the following infrastructure in this
guide:
·
2 windows 2008 R2 domain controllers
(forest/domain level 2003 native).
·
1 Exchange 2007 SP3 server (all Exchange 2007
servers need to be SP2 minimum. Preferably SP3).
·
1 Exchange 2010 SP2 server.
The infrastructure used is the same as the servers that were
used for the “Transition from 2003 to 2007” and the “Exchange 2007 CCR” guides.
Preparation
As always we first need to be sure our AD is in a healthy
state and no replication errors are occurring. Secondly the Exchange needs to
be in a healthy state, yet if you only have one Exchange server in the
environment this will be likely the case.
Note that if you are planning to set
up a DAG and/or CAS array you will
need the enterprise license for windows!
Once you have your base OS (windows 2008 R2) for the Exchange
2010 server set up and configured install the active directory tools on it from
the features menu:
1.
Open servermanager
2.
Add features
3.
Expand down to Remote server administration
tools, Role administration tools, ADDS and AD LDS Tools
4.
Select AD DS Tools and confirm the pre
requisites pop up box.
5.
Next, Install, Finish.
6.
Reboot.
Now go download the office 2010 filter packs so setup won’t
nag you about it (http://www.microsoft.com/download/en/details.aspx?id=17062).
They do add in some functionality but I’m not going into depth on that subject
here.
Now that you have the AD DS tools & filterpacks
installed you are ready to prepare your forest and domain for Exchange 2010.
You could run the following commands on a domain controller but I tend to run
them from the Exchange server with AD DS installed, personal preference but it
does minimize hopping from server to server J.
The really, really wonderful thing about the Exchange 2010
setup process is that it will handle all installation of prerequisites and even
the preparation of the forest and domain! If you want to do each step manually
that is still possible using the setup.com in the setup folder.
Installation
Go ahead and launch setup and start the installation. Read
through the introduction and accept the EULA. Once again we are faced with the
error reporting option, up to you whether you want to help out Microsoft or
not.
Now, as you can see on the following screen there is a
checkbox at the bottom you can use to have setup automatically install whatever
it needs for the installation. Check this, change the install directory if
desired and select the Typical Exchange server installation. Click next.
New screen! Setup comes and asks you if the CAS server will
be internet facing, basically if clients will connect to it from over the
internet (outlook anywhere, owa,…) so check the box and give the domain name
that will be used for external clients.
Our next screen is the Customer experience improvement
program. Just like error reporting, signing up for this is up to you! Once you
click the next button setup will prepare and configure the prerequisites for
Exchange.
Once every prerequisite has been configured the install
button will be available, take the leap and install Exchange 2010. It will take
quite some time so site back, relax and have a coffee.
Once the setup has been completed you will be asked to
reboot before placing the server in production. So go ahead and do that right
now.
At this point you’d want to perform the following actions:
1.
Enter your product key
2.
Configure the receive connector
a.
Open the EMC
b.
Drill down to Server Configuration, Hub
Transport.
c.
Right click “Default Servername” and select
properties
d.
Open the permission groups tab
e.
Check anonymous users
f.
Click ok
3.
Enable outlook anywhere
a.
Open the EMC
b.
Drill down to server configuration, client
access
c.
In the right actions pane choose “Enable outlook
anywhere”.
d.
Select your authentication mechanism
i.
Basic will make your users enter a password each
time the open outlook
ii.
NTLM will use windows integrated authentication
(username and password)
e.
Enter your external host name
f.
Click the enable button
4.
Modify your firewall rules so that all external
traffic is sent to the 2010 server.
5.
Replicate public folders if necessary
6.
Move over users in batches if required
a.
Open EMC
b.
Drill down to Recipient configuration, Mailbox
c.
Select the users you want to move
d.
Right click and select “new local move request”
e.
Use the browse button to select the target
mailbox database
f.
Next, next, new, finish
Note here that this only creates a request to move the
mailbox and the actually moving will be done in the background! To view the
status of the move requests go to the Move request section under recipient
configuration. You have to manually remove the completed requests by right
clicking them and selecting “clear move request”
7.
Change the generation server for the OAB
a.
Open the EMC
b.
Drill down to organization configuration,
mailbox.
c.
Open the offline address book tab
d.
Right click the default OAB and select move
e.
Use the browse button to select the 2010 server
f.
Click move, finish.
8.
Remove the Exchange 2007 servers.
Theoretically this is all you should have to do to migrate a
pure environment without funnies. There might be additional services on the
network that require configuring but this should have been identified before
you start the migration. Hopefully…
The background workings of a CCR can be quite mysterious but
are, all in all, not that difficult to understand. First of all we need to know
the following things:
·
There are two fundamental elements for the
Exchange store:
The transaction logs and the database
·
Transaction logs are a maximum of 1 MB in size
(in Exchange 2003 this was 5MB)
·
Log files are stored in sequence and in the
following format:
E(number of the storage group)(8 digit hexadecimal number).log
·
The checkpoint file (EDB.chk) stores which log
files have been written to the database
·
Log files are only cleared if a successful full
backup has been performed
There are five (5) subcomponents that make up the ESE and
define the process of moving database in to the database!
Log buffers
When a transaction is first received it is stored in the log
buffer. These log buffers are used to hold the received information in the
servers memory before the data is written to the transaction logs. The
following parameters define a log buffer:
·
Each buffer unit is the size of a disk sector
(512 bytes)
·
JET will perform sanitation so that they are a
minimum of 128 sectors, a maximum of 10,240 sectors and that the largest 63KB
boundary is aligned.
Log writer
Once the log buffers are filled up the data is moved on to
the disk and in to the log files. This committing of the data is performed in a
synchronous fashion and very fast to assure that a system failure would not
cause data loss.
IS Buffers
The IS buffer is the first step to turning the transactions
to actual data. Grouped in 4KB pages allocated from memory by Exchange, they
serve the purpose of caching the database pages before being written to disk.
When the pages are first created they are marked as clean as
there is no data written to them. Once the ESE plays the transactions from the
logs into the empty pages in the memory it changes the status to “dirty”.
Version store
Since ESE writes multiple different transactions to a single
page in the memory the version store is needed to, not only keep track of these
transaction, but also to manage them. It structures the pages that occur as
they occur.
Lazy writer
When the ESE gets to the point the dirty pages need to be
flushed out of the memory it calls the lazy writer to move the pages from the
cache buffers to the disk. As there is a large number of transactions going on
at once it is the job of the lazy writer to prioritize the transactions and
subsequently handle its task without overloading the disk I/O subsystem.
At this point the transactions in the memory have become
static information on the disk and the dirty memory caches are cleaned up and
ready to be used again!
The checkpoint file
There are two notable components of the database checkpoint,
Namely the checkpoint file and the checkpoint depth.
The checkpoint file (edb.chk) is a file maintained by the
database engine for every log file sequence to keep track of the data that has
not yet been written to the database file on the disk. It is a pointer in the
log sequence that indicates where in the log file the information store needs
to start recovery in case of a failure. Without the checkpoint file the
information store would start replay from the beginning of the oldest log file
on the disk and it would have to check every page in every log file to
determine whether it had already been written to the disk.
The checkpoint depth is a threshold which defines when the
ESE begins to aggressively flush dirty pages to the database.
ESE Cache
The ESE cache is an area of memory reserved to the
information store process (running under store.exe) used to store database
pages in memory, reducing read I/Os and
increasing the performance of Exchange.
The EDB file
As the main repository for the mailbox data the fundamental
construct of the edb file is that of a table. Hence the need to run ISINTEG in
case the edb file gets corrupted as only ISINTEG can fix the tables in the EDB
file.
How it comes together
Imagine a client sends a new message. The page that requires
updating is read from the file, placed in the ESE cache whilst the log buffer
gets notified and records the new transaction in the memory of the server.
These changes are recorded by the database engine but not
immediately written to disk. The changes are held in the ESE cache and marked
as dirty bits so signal they have not yet been written to the database
(committed if you would like to call it that). The version store is used to
keep track of the changes, guaranteeing consistency.
As the database pages are changed, the log buffer is
notified to commit the changes and the changes get written to a transaction log
file. Eventually the dirty database pages are flushed to the database files and
the checkpoint is advance.
The CCR functionality
Now that we know how
the transactions get written to the log files we can go further and explain how
the CCR gets to replicating and replaying these changes!
In a CCR we have two nodes, an active and a passive node,
one which pulls transaction files to the other. The active node is where all
the clients with their MAPI sessions will connect to, the passive stands by in
case of the failure of the active node with its own copy of the database and
log files.
The technology behind the CCR is based on an asynchronous
copy, meaning that the passive copy does not get the information from the
transaction log replayed in the database at the same time as the active node.
In fact, the passive node cannot pull the transaction log file over to replay
it unless the active nodes store process has released the log file (aka is done
replaying the log file to the database).
So if we continue on our earlier premise, one the checkpoint
on the active node is advanced the passive node pulls the log files it still
needs to replay over and replays them in to the database.
Source:
http://www.windowsitpro.com/article/john-savills-windows-faqs/q-how-does-cluster-continuous-replication-ccr-work-in-microsoft-exchange-server-
http://blogs.technet.com/b/mbaher/archive/2008/01/22/who-said-that-transaction-goes-from-logs-to-db.aspx
Introduction
The CCR cluster in Exchange 2007 allows your environment to
become fault tolerant (up to a level) and is the basis of the 2010 DAG
technology. Whilst it is a bit of a fairy/drama queen when it comes to
replication (in my opinion) it’s easier to manage and set up than a 2003 high
availability cluster.
A certain number of requirements apply to a CCR cluster:
·
You must have the failover clustering component
on your OS (So enterprise/datacentre licenses are required)
·
You’ll need a heartbeat network interface
·
A file share witness is required on a third
server
·
A CCR can only run on a mailbox only server. So
no sharing of Exchange roles…
·
Updating is a bit more complicated.
·
Management becomes more “difficult” versus a
normal installation of Exchange.
So for this tutorial we’ll be using the following
infrastructure:
·
The environment we setup in the transition from
2003 document
·
2 extra 2008 enterprise server
·
Exchange 2007 SP3.
Preparation and prerequisites
As mentioned before you need an enterprise license minimum
and a heartbeat nic for both servers. Once you have everything configured on
the OS level we can start configuring the servers for the CCR cluster! The
first thing we have to do is install & configure the clustering component
for windows 2008.
·
Add features
·
Select Failover Clustering
·
Next
·
Install
Repeat on the second server in your CCR Cluster. As soon as
you have configured this on both server (reboot might be required, but did not happen in my case) open up the
failover cluster manager and select the “validate a configuration wizard”.
Enter the names of the servers and click next.
Select the radio button in front of “run only tests I select”
and click next. Uncheck the storage part (a
CCR does not use shared storage!) and click next, next and wait for
completion. If the results of the tests are all “passed” you are good to go, if
not, review why it failed and correct where possible.
When all tests are returned in the green select the “create
cluster wizard”. For the time being only enter one server name in the
selection. Since you already ran the validation wizard you can ignore the “validation
warning” window.
Name your cluster and give it and IP, click on next, next
finish. Now in the failover cluster manager expand the nodes and select the
action “add node”. Go through the wizard until finished J. Open up the networks section
in the cluster manager and rename the networks according to their function.
This helps troubleshooting in case something would go wrong in the future… On
the heartbeat network, the checkmark “allow clients to connect through this
network” needs to be unticked. Double check this is the case.
Now on each server run the following commands to install the
prerequisites for Exchange 2007.
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-ISAPI-Ext
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Windows-Auth
Now, on the server you elected to use for the File Share
Witness, open a command window (DOS prompt) and perform the following actions:
·
MKDIR FSW_CCR_MAIL
·
NET SHARE FSW_CCR=C:\ FSW_CCR_MAIL
/GRANT:CCRCLUSTER$,FULL
·
CACLS C:\ FSW_CCR_MAIL /G
BUILTIN\Administrators:F CCRCLUSTER$:F
Note that CCRMAIL$ is
the actual computer name you configured your cluster with, in my case mail$.
Now, on your failover cluster, right click, nore actions,
configure cluster quorum settings. Select the “Node and file share majority”
option and click next. Now browse to the shared folder path, click next, next
& finish.
Installation
Time to start the installation! Fire up the Exchange setup
and opt to install Exchange server 2007…
Once setup has started select “custom Exchange server installation” and check
the “active clustered mailbox role” checkbox. If necessary change the
installation path. On the next screen make sure cluster continuous replication
is selected and specify the name for the CCR (needs to be different from your
cluster name!). Use the screen that follows to assign an IP address (again,
this needs to be different from the cluster IP) and let the installation do its
work on the server. Once setup completes reboot the server.
Now that the first node has rebooted and is up and running, turn
your attention to the second server. Launch setup on this server and select the
custom installation option, but select the passive clustered mailbox role
checkbox this time over. When the prerequisite checking has completed press the
install button and wait for setup to complete.
Finishing up
Now that the installation has been completed open up the
Exchange management console and expand the server configuration > Mailbox.
As you can see the individual server you installed Exchange on are not listed,
instead the cluster name has been listed as a mailbox server.
At this point you can go ahead and move the databases and
log files to a different drive. The recommended configuration is that both the
database and the log files are on a different physical spindle (hard drive) for
optimum performance. Before telling you how to move the files to a different
path you’ll have to note that the hard drive configuration needs to be the same
on both CCR nodes. That means the drive letters need to be the same! Ideally
you would have the same hard drive space available on both nodes as well as you
don’t want either server to run out of disk space.
Now, to move the database and log file path follow this
process:
1.
Suspend the storage group copy:
Suspend-StorageGroupCopy
-Identity <Server\StorageGroupName>
2. Dismount
the database:
Dismount-Database
-Identity <Server\StorageGroupName\DatabaseName>
3. Move
the database files:
Move-DatabasePath
-Identity <Server\StorageGroupName\DatabaseName> -EdbFilePath
<NewPath> -ConfigurationOnly
4. Move
the logfiles folder path:
Move-StorageGroupPath -Identity:<Server\StorageGroupName>
-LogFolderPath:<NewPath>
-SystemFolderPath:<NewPath>
-ConfigurationOnly
Note that you have to use the configurationOnly parameter and manually move the database files on
both the active and passive node!
5. Mount
the database:
Mount-Database
-Identity <Server\StorageGroupName\DatabaseName>
6.
Resume the storage group copy:
Resume-StorageGroupCopy
-Identity <Server\StorageGroupName>
7.
Check that replication is occurring and the replication
status is healthy.
1.
In the lifespan of an organisation it’s messaging environment be transitioned to a newer version several times. Whilst this is not a complicated thing to do it does require some level of planning and thought. I’ll be addressing the transitioning from Exchange 2003 to 2007 from a fairly simple view here. Since the general outlines of the process are the same for nearly every situation there is no need for different detailed documents on this.
We’ll be working with the following infrastructure in this guide:
· 2 windows 2008 R2 domain controllers
· 1 Exchange 2003 SP2 server
· 1 Exchange 2007 SP3 server.
Since this is a transition from a legacy environment there are some more steps to take than if we would be straight up installing a completely new Exchange 2007 environment. I will not neglect to point out some things that you might need to differently in case you would have a slightly different environment. So let’s get started!
Preparing the environment for Exchange 2007
Installing Exchange 2007 in an existing legacy environment firstly require you prepare the legacy permissions. Since the architecture of Exchange 2007 changed quite a bit (f.e. no more routing group connectors!) this will prepare the legacy Exchange environment RUS to work properly whist the 2007 servers are there.
First of all, you need to make sure your Exchange 2003 environment is in native mode:
1. Open Exchange system manager
2. Right click the very top level item (in my case: toasterlans (exchange))
3. Select properties
4. Make sure the operation mode is in Native mode (aka no Exchange 2000 servers). If it is not, upgrade it by clicking the button below operation mode.
5. Now switch over to the future
Exchange 2007 server (make sure you are logged on to the domain)
6. Open a command prompt as administrator
7. Navigate to your installation media
8. Type in “setup.com /preparelegacyexchangepermissions”
9. Setup will start to prepare the domain and
Exchange 2003 with legacy permissions.
The next step is to prepare the Active Directory Schema:
1. Switch over to the future Exchange 2007 server (make sure you are logged on to the domain)
2. Open a command prompt as administrator
3. Type in servermanagercmd –i RSAT-ADDS
4. Reboot
5. Logon on and open a command prompt as administrator
6. Navigate to your installation media
7. Type in “setup.com /prepareschema”
8. Wait for completion…
Note that we installed the RSAT-ADDS component on our server to allow setup to contact the active directory. If you do not wish to install this component (it will get installed later on anyways) you can opt to run the prepare schema and AD operation on a domain controller.
And finally our last step in preparing the environment for Exchange 2007
1. switch over to the future Exchange 2007 server (make sure you are logged on to the domain)
2. Open a command prompt as administrator
3. Navigate to your installation media
4. Type in “setup.com /prepareAD”
5. Wait for completion…
Now that the routing group connectors, the permission and the schema have all been dealt with we can start installing
Exchange 2007 in to our environment!
Installation
First of all it might seem I’m missing something here, where are the prerequisites? Your totally right there… Put in the following commands to get those prerequisites on the machine…
Servermanagercmd –I RSAT-ADDS (if you didn’t install this earlier)
Reboot
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Powershell (installed by default on 2008 R2)
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-ISAPI-Ext
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Digest-Auth
ServerManagerCmd -i Web-Windows-Auth
ServerManagerCmd -i Web-Dyn-Compression
ServerManagerCmd -i RPC-over-HTTP-proxy
So go ahead and start setup and click the start Exchange 2007 SP3 installation.
Read through the new features, click next. Accept the license agreement and click next.I usually leave error reporting on, but your mileage might differ. Now on the next screen we have the option between a typical installation and a custom installation. Since this is about a simple all in one server transition, select typical. If you need to change the installation path this would be the time to do so! Click next.
The following screen requires you to select a server in the routing group connector that
Exchange 2007 will connect to. Basically this means that all mail flow between the organisations will go through that server. So click browse and select the appropriate server.
Setup will perform some prerequisite tests and check for updates. This might take a while so go and get yourself something to drink. When this ends you might get some warnings. Take note of them and press “install”.
Installation will, once again, take a while depending on your hardware speeds. We’re almost done installing Exchange so no panic! Once the installation is completed you can go ahead and click finish J. You’ll probably get presented by a popup asking the server to reboot before placing it in production, quickly followed by the EMC opening up.
Now, before we move users on to the server we will have to reboot, but first we want to make some configuration changes to the server.
Configuration
Accepted domains
First of all we need to configure the accepted domains J.
1. Open the EMC
2. Open Organization configuration
3. Open Hub transport
4. Open the Accepted Domains tab.
5. Check that all domains have been transferred from the 2003 server
6. Open the email address policies tab
7. Check that all policies have been transferred from the 2003 server.
Mailflow
1. Open the EMC
2. Open the Server configuration section
3. Open Hub Transport
4. Right click the default receive connector
5. Open the permission groups tab
6. Check the anonymous users checkmark
7. Go back to the organization configuration
8. Open hub transport
9. Click on the send connectors tab
10. Create a new send connector by choosing that action in the right pane
11. Name it
12. Choose internet from the intended use drop down list
13. Next
14. Click on add
15. In the address field add “*”
16. Click on OK, next
17. If you have a smarthost use the information in this section
18. Click on next, next, new, finish
With these steps completed you can now send and receive mail through the Exchange 2007 servers! Go ahead and reboot the server before proceeding any further. With the server there is still a number of other tasks that need to be performed; Replication of the public folders, moving the database, OAB generation servers and removing the Exchange installation.
Replicating all public folders
1. Open the EMC
2. Go to toolbox
3. Open Public Folder management Console
4. Configure replication as follows:
a. Right click the public folder you want to replicate
b. Properties
c. Replication tab
d. Add
e. Select the server you want to replicate with
f. Press OK, OK
Note that you will have to replicate the free busy data if you are using outlook 2003 clients! Once the public folders have replicated proceed with the steps below…
Point all external links to the Exchange 2007 CAS servers at this point
Transition
Moving mailboxes
1. Open the EMC
2. Go to recipient configuration
3. Open the mailbox section
4. Select the users you want to move (use batches if possible)
5. Right click
6. Move mailbox
7. Browse to select the Exchange 2007 mailbox store
8. Next
9. Next
10. Next
11. Move
12. Sit back and enjoy
OAB Generation server
1. Open EMC
2. Expand organization configuration
3. Expand mailbox
4. Offline address book tab
5. Right click the default offline address book
6. move
7. Browse to select the new server
8. Move
9. Finish
10. Right click detault offline address book
11. Properties
12. Distribution
13. Enable web-based distribution
14. Add
15. Select the web directory
16. OK, OK
The last seven steps will allow all outlook 2007 and 2010 client to use web distribution to download the OAB.
Removing the routing group connector:
· Get-routinggroupconnector | remove-routinggroupconnector
Moving the RUS
1. Open system manager on the 2003 server
2. Expand recipients node
3. Expand recipient update services
4. Perform the following for both items listed:
a. Right click
b. Properties
c. Brose next to Exchange server
d. Select the Exchange 2007 server
e. OK
f. OK
Uninstalling Exchange 2003
1. Open the control panel
2. Add or remove programs
3. Exchange 2003
4. Change/remove
5. Select remove from the drop down menus
And you are now finished, running completely on Exchange 2007! Of course this was a very basic guide and there are a ton of things more you can do with Exchange 2007 that we’ll cover in upcoming articles!
Exchange is a complex and large product which can have one thousand and one possible issues, one more obscure as the next. The purpose of this guide is to shed some light, where possible, to how things work in Exchange (and outlook), how they can break and how you should approach the issue at hand. Unfortunately it is very time consuming to create a complete troubleshooting guide where every dependency is explained in detail. But that is not the aim of this document anyways.
What is the aim? Give you, the engineer, a way to solve the most common of scenarios and information on how that piece of technology actually works. Note that there are a significant number of differences between the different versions of Exchange, which could give you a different solution for each problem.
In troubleshooting we need as much information as we can get. Not only do we need product knowledge but we also need to know what the problem is! Who, what, where and when would be the main pillars of that knowledge and the following items will allow you to question the client and narrow down the problem…
A number of questions (and follow ups) can be asked when contacting the user that will help you determine the scope, depth and impact of the issue. The following questions should give you an insight in to what is going on and help you determine where to look.
Maybe the most pinnacle of questions for troubleshooting an issue! With this you can add depth to the impact of the issue (CEO vs. cleaning lady) and if it is limited to only a number of users you know that similarities must exist, on some level, to have the issue occurring to a defined number of users. On the other hand, if everybody is having the issue, you can determine if the issue is occurring on the client or on the server level.
Determining the impact will help you prioritizing. It should also give you a level of understanding in what kind of solutions you can apply. If everyone is down, well, there is no real issue with going for disruptive actions as no one can currently access the system anyway…
You would be surprised in how much this can help you track down the source of the issue. Did it start today, yesterday or last week? Maybe even years ago (yes there are users that will wait years before reporting an issue and expect you to solve it in minutes >_<).
Apply common sense when asking this question. Some people will get offended but it can be very helpful in finding out if something broke or there is a setting wrong…
No problem without an error, that much is simple. Something not working, an outlook error code returned when connecting or something showing up in the event log. Each and every one of these will help you out in solving the issue faster and better.
With all the information you have obtained from the user you should be getting an idea on what is going on and what the impact of the issue is. If you know the solution to it, you can skip this section, on the other hand, if you need more information you can use the following tools to narrow down specific items and get more information on them.
Maybe the single most useful tool in helping you solve a problem! Exchange errors will be logged in the application log most of the time and rarely one or two in the system log.
ExBPA is a neat little tool built in to the Exchange Management Console allowing you to run some reports and get information on configuration errors in Exchange. Note that it can create performance baselines as well as check if the environment is ready for Exchange. If you are running Exchange 2003 you will have to download exBPA (here) as it is only present in 2007 and 2010.
Also known as ExTRA and just like the ExBPA it is built in by default in to the EMC. It contains a number of common troubleshooting paths and can be very useful to collect data automatically instead of having to scour through different manual paths. The version for Exchange 2003 is available here.
Yes, this little client can be helpful although it is limited in to testing mailflow. Remember that on windows 2008 and up you will have to install the client before you can be able to use it. Don’t worry though. No reboot is required J. Commands to test mail flow:
EHLO toasterlabs.com
mail from: marc.dekeyser@toasterlabs.com
rcpt to: administrator@toasterlabs.com
data
Blablablabla
.
quit
You can get more information on this from the following URL:
http://www.samlogic.net/articles/smtp-commands-reference.htm
Increasing the event log levels is a great way to get more information on what is going on logged in the event viewer (as well as to get your event logs flooded). Slightly different to use in Exchange 2003 and 2007/2010 but the result remains the same.
Exchange 2003: Right click the server object in the Exchange system manager console and go to the “diagnostic logging” tab. Increase the logging to the highest level for the entries related to the issue you are troubleshooting.
Exchange 2007/2010: I prefer the powershell route to increase the logging in these versions of Exchange. You can get the current eventloglevel by using the following command:
Get-eventlogloglevel
From this you can mark and copy the desired item you want to increase logging on by using the following command:
Set-eventloglevel –identity “MSEXCHANGESA\OAL GENERATOR” –Level High
Note that you can also pipe these commands if you want to increase everything in a certain set.
Get-eventloglevel MSEXCHANGSA\* | set-eventloglevel –level high
You can find more information about the commands used and the different levels at the following technet link:
http://technet.microsoft.com/en-us/library/dd335139.aspx
If you are running in to performance issues you can use the OS built in perfmon to see what is causing your slow down. A detailed description of the performance counters are available here:
http://technet.microsoft.com/en-us/library/dd335215.aspx
This Microsoft website allows you to test autodiscover, RPC over HTTP and activesync connections. Note that you will need a username, password, domain name and email address to test the connections. No information is stored on the Microsoft servers so in theory you are not required to use a test account, yet I still recommend it.
https://www.testexchangeconnectivity.com/
More security oriented, the MS BSA allows you to scan for security updates present and missing from Exchange 5.5 servers and later. Download from here.
As the name of the tool suggests, this tool would be used to administer and troubleshoot public folders. Download from this location.
ESEUTIL
A great tool for database recoveries! This tool will fix the edb file by either replaying log files in to the database or changing the log file replays required to get out of a dirty shutdown. There are a number of different options to run with this tool but the most important ones would be the following:
· Check for shutdown state (/mh)
· Offline defrag (/D)
· Hard recovery
· Soft recovery
You can get more information on this tool right here.
ISINTEG
This tool should always be used after running an eseutil repair. Whilst eseutil will fix the physical file it is not aware of the table structure used in an edb file. ISINTEG is specifically designed to fix the table structure where possible (and chuck the data if it is FUBAR).
To run isinteg your information store needs to be running so make sure that is happening. Typically you would run it in the following context
Isinteg –s servername –tests alltest –fix
More information is available here.
There are even more tools available from Microsoft that are not directly linked to troubleshooting yet still deserve a place in this document as they might come in handy at one point:
· Exchange 2007 Anti-Spam migration
· Exchange server Jetstress
· Exchange server stress and performance
· Exchange load generator
· Exchange server profile analyser
More information on these tools (and their download locations) can be found here:
http://technet.microsoft.com/en-us/exchange/bb330849
Until next time!
Technorati Tags: Microsoft,Exchange,product,purpose,outlook,dependency,Give,scenarios,information,technology,Note,
differences,versions,solution,Where,knowledge,pillars,items,client,user,scope,depth,impact,Maybe,pinnacle,
users,similarities,server,solutions,system,Some,error,event,Tools,Eventviewer,tool,errors,ExBPA,Management,
Console,configuration,performance,environment,Also,ExTRA,paths,data,version,Telnet,Remember,Commands,
EHLO,administrator,Blablablabla,reference,viewer,manager,Increase,From,item,MSEXCHANGESA,GENERATOR,
Level,High,MSEXCHANGSA,library,description,Remote,Analyser,password,domain,servers,theory,account,Download,
Public,Folder,admin,folders,location,Anti,Spam,migration,locations,toasterlabs,eventloglevel,techne
During the lifespan of an Exchange server a database can become very, very large in the size it takes on the disk, much larger than the space used by the mailboxes that reside in the database. This is because whilst mailbox sizes will expand and shrink according to their data usage, the Exchange database only expands. Any space freed up by deletes in mailboxes or even the removal of a mailbox all together become whitespace in the database file. In the worst case you could have 40 GB of mailboxes yet a database that is consuming over 100 GB!
Unfortunately in Exchange 2003 the only way to shrink that database is by performing an offline defrag, bringing your mail users offline for the time it takes to perform the operation. An alternative is to create a second mailbox database and move all the mailboxes to this database allowing you, once completed, to delete the original database file.
Whilst this is a viable option for enterprise editions the Exchange 2003 standard edition is limited to 1 mailbox database. Not very handy…
A work around for this is to use a dial tone recovery database to allow your users to keep receiving and sending email while you perform an offline defrag. Downside of this is that any user who is in online mode will not have access to their older emails.
A dialtone database is, in essence, a temporary database you can use when the original edb file is corrupted and you do not want to have your users go offline during your attempts to save the original edb file. Using this method does bring in a bit of administrative overhead as you need to perform a recovery storage group merge later on, the need to go ahead with this operation relies solely on the situation…
In Exchange 2007 and 2010 a powershell commandlet has been introduced allowing one to clean up this whitespace whilst the database is still online. It runs against one or all databases at a time and might take some time to complete.
To run it against one database:
Clean-mailboxdatabase –identity “Database name”
To run it against all databases:
Get-mailboxdatabase | clean-mailboxdatabase
Technorati Tags: lifespan,server,database,size,disk,mailboxes,mailbox,sizes,data,usage,removal,users,
enterprise,editions,edition,recovery,Downside,user,mode,essence,method,storage,situation,Exchange,
databases,Clean,whitespace,defrag,mailboxdatabase
As you might, or not, be aware off there is no item level based recovery in Exchange that is natively supported by Microsoft. So to perform recoveries we need the recovery storage group (captain obvious). The purpose of this is to mount the database you want to recover from on the Exchange server and use exmerge to merge the data you are recovering into the active database. An RSG will not be accessible to users and you can only create one at a time.
Exchange 2003:
1. Open Exchange system manager
2. Drill down to the server you want to recover to
3. Right click the server and select New > Recovery storage group
4. Specify the drive you have restored the database to. If possible use the same drive as the active database as this will improve performance quite a bit.
5. Click ok J
6. Right click the RSG and select “Add database to recover”
7. Select the right database you are going to recover.
8. Make sure that “This database can be overwritten by a restore” is checked (by default is should be)
9. Mount the database
10. Select the database in the recovery storage group, open the mailboxes container .
11. Select and right click the user(s) you want to restore.
12. Run Exchange task from the menu
13. Select the “recover mailbox data” task
14. Depending on your situation select either the Merge data or Copy data context
15. Schedule if necessary
16. Watch as your data is getting recovered.
Once this process is complete all data will be where it is supposed to be once more!
Exchange 2007:
1. Open up the Exchange management console
2. Go to the tools subset and open the Database Recovery Management tool
3. Select the storage group you want to link to the RSG
4. Double check the information presented in the next screen and click the Create the recovery storage group.
5. By default the RSG will be linked to the following folder: C:\program files\microsoft\exchange server\mailbox\<storage group>\RSGxxxxxxxxxx
6. Recover files to the RSG folder
7. Once recovered g o to the recovery storage group management tool and slect to mount the database.
8. Once mounted, go back to the task center and select Merge or copy mailbox contents
9. Make sure the proper database is selected and click on the gather merge information.
10. If you are dealing with a dial tone database click the “Swap database configurations” checkmark. If not, just click next
11. Click the Perform Pre-merge task
12. Select the mailboxes you wish to recover and let ExTRA do its thing.
13. Once the process is completed use ExTRA to dismount and remove the recovery storage group. Once that has been done you manually can remove the files in the RSGxxxxxxxx folder.
And that is it!
Exchange 2010:
1.
Open the exchange management shell
2.
Type in the following:
a.
New-mailboxdatabase “name” –server “servername”
–recovery:$true –edbfilepath “path to restored edb file”
b.
Mount-database “name of DB you just created”
c.
Get-mailboxstatistics –database “name of restored
database”
d.
New-mailboxrestorerequest –sourcedatabase “name
of recovery database” –sourcestoremailbox “Username” –targetmailbox “emailaddress
of target mailbox”
That will create a new recovery request. You can view the
state of the request by using:
Get- MailboxRestoreRequest
Once completed, remove the request with
Get- MailboxRestoreRequest –status completed |
remove-MailboxRestoreRequest
And that is it!
EDIT: Added the 2010 section :)
Technorati Tags: Recovery,storage,item,Microsoft,recoveries,purpose,database,server,data,users,Exchange,Open,system,
manager,Drill,Specify,performance,Click,Select,Make,Mount,mailboxes,user,task,menu,mailbox,situation,
Merge,Copy,context,Schedule,Watch,Once,management,tools,subset,tool,Double,information,Create,folder,
RSGxxxxxxxxxx,Recover,Swap,configurations,Perform,ExTRA,RSGxxxxxxxx