Category Archives: Uncategorized

Installing a Continuous Copy Replication or CCR Cluster Part2…

Uncategorized

 

Okay, time to get down to the nitty gritty, actually installing a CCR cluster!!  First lets take a look at what we have in our environment already:

Existing_Env

We have already installed two separate Hub Transport/Client Access Server, NYHT01.ponzeka.test and NYHT02.ponzeka.test.  We have two more servers who are going to be our CCR nodes, NYCCRNODE1.ponzeka.test and NYCCRNODE2.ponzeka.test.  They will eventually be part of the CMS, NYMB01.ponzeka.test.

There are several things to note.  First, each of the nodes need a “heartbeat” network to speak to each other.  This is the network that allows the separate nodes to kind of keep tab of each other, and determine if the other node has failed, and if it needs to take over the CMS.  This should be separate from your production network.

Next, notice that NYMB01.ponzeka.test has two IP’s.  One, 10.2.1.110, is the actual IP that the users will see as the server, NYMB01.ponzeka.test will resolve to this IP.  The other IP, 10.2.1.111, is the cluster management IP address.  This is used to connect the Microsoft Cluster Management Console to, in order to manage the cluster as a whole.

The first thing we need to do, before we even install Exchange, is to actually create the cluster.  On NYCCRNODE1, we need to configure the separate networks, one for production that clients will connect to, and the second for the heartbeat network.

ScreenHunter_02 Feb. 14 11.31

So, if we notice we have one NIC already labeled as “Production”.  There aren’t any settings you need to change for this.  We do need to make some changes to the heartbeat connection.  The first thing we need to do is configure the IP address of the heartbeat adapter:

ScreenHunter_03 Feb. 14 11.33

There isn’t a need to configure a default gateway or DNS servers.  Next select the Advanced button, then the DNS tab.  Make sure you un-check the “Register this connection’s address in DNS”

ScreenHunter_04 Feb. 14 11.34

Now go to the WINS tab.  Check “Disable NetBIOS over TCP/IP”:

ScreenHunter_05 Feb. 14 11.35

Save all your settings and close the NIC properties box.  Back in Network Connections, select “Advanced-> Advanced Settings”.  Here, make sure that your Production connection is the highest.  Also, un-check “File and Print Sharing for Microsoft Networks” on the heartbeat adapter.

ScreenHunter_06 Feb. 14 11.38

Click OK to save the settings.  Now, configure the same network properties on NYCCRNODE2.ponzeka.test.  Of course, make sure you use unique IP addresses.  After you have configured both on each node, make sure you can ping each server through its respective heartbeat, as well as production networks.  Resolve any issue before going forward.

Now, its time to create the cluster.  Remember, this has to be done before you install Exchange.

Go to Start Menu –> Administrative Tools –> Cluster Administrator.  Under “Action”, select “Create a New Cluster”

ScreenHunter_07 Feb. 14 11.43

You’ll be presented with the New Cluster Wizard. It will ask for a Cluster Name.  This must be a valid computer name.  This should NOT be what you want your exchange server CMS name to be.  In our example, we want our CMS name to be NYMB01.ponzeka.test.  The name you enter in this screen, is just for management of the cluster.  We’ll use ManagementCCR.  The cluster wizard will automatically register this name in DNS so you can use the name ManagementCCR.ponzeka.test to connect to the management tools instead of the IP:

ScreenHunter_08 Feb. 14 11.47

Next, it will ask you for the first node in the new cluster.  It will by default input the name of the server you are working on:

ScreenHunter_09 Feb. 14 11.48

Next, the wizard will test the feasibility of the cluster.  You will receive warnings because there are not shared resources that will be available to multiple nodes.  This is fine, remember, this is a “Share Nothing” Cluster.  Select Next:

ScreenHunter_10 Feb. 14 11.49

Next it is asking for the IP address for management of the cluster.  Again, this will NOT be the IP address end users will connect to for exchange services.  This is simply for the management of the cluster.  We earlier stated we would be using 10.2.1.111 as the management IP.  Input that here and select next:

ScreenHunter_11 Feb. 14 11.51

Next, you are asked to provide a cluster service account.  This can be a standard domain user account, but it will be given administrative access to each node in the cluster.  Because this is simply a test environment, we will use the admin account, but do not do this in production!

ScreenHunter_12 Feb. 14 11.52

At the next screen you could just select next, and finish the cluster, and chances are it would work fine.  However, notice the quorum button on the bottom right.

ScreenHunter_13 Feb. 14 11.54

We can select the “Majority Node Set”.  This is a new clustering ability provided to us by Microsoft.  Essentially, we will use a share located on a third server, completely separate from the cluster to hold the Quorum data.  This will allow a total of three votes in the cluster.  Two votes would be needed to initiate a failover.  This ensures a more consistent and accurate detection of node failures and cluster failover.  Microsoft recommends the third server, be a Hub Transport server in the same site as the two cluster nodes.

Select OK, and next.  The wizard does a final analysis of the cluster.  You should receive no errors or warnings here, if you do resolve them before moving forward.  Click next and finish, and you should have your cluster!

ScreenHunter_14 Feb. 14 11.59

Now we need to add the second node to the cluster. Simply right click on the name of the management node and select New –> Node.

Browse for the computer name and select Add:

ScreenHunter_16 Feb. 14 12.01

Select next.  Now the wizard will check the configuration to ensure everyone is working.  You should receive no warnings or errors.  Select next.

Enter the password for the cluster service account:

ScreenHunter_17 Feb. 14 12.02

Select next, and then after the summary page, select next to add the node.  At the last screen you should again receive no warnings or errors.  You should now have both nodes in your cluster:

ScreenHunter_18 Feb. 14 12.05

So we have completed setting up the initial cluster configuration.  Next, we need to set up the file share witness for the Majority Node Set.  We are going to use NYHT01.ponzeka.test as the file share witness. 

On NYHT01, create a folder and share it out.  Make the name descriptive:

ScreenHunter_01 Feb. 14 12.10

Change the security settings so that NTFS permissions do not inherit.  Make sure domain admins (or any specific group that manages clusters) has Full Control, and that the cluster admin account has Modify:

ScreenHunter_02 Feb. 14 12.13

Now, we have the file share created.  We need to activate it in the cluster.  Log back into NYCCRNODE1.  Start up command prompt and type the following command:

Cluster res “Majority Node Set” /priv MNFSFileShare=\NYHT01ManagementCCR_FSW and press enter:

ScreenHunter_19 Feb. 14 12.16

The warning you receive is expected.  It’s telling you that the change won’t take effect until after the next time the resource is brought online.  Luckily for us, this is easy to do!  You simply need to move the resource over to the secondary node.  In Cluster Administrator, expand groups.  Now right click on Cluster Group and Select “Move Group”  this will cause the cluster to offline, move to the second node and come back online. 

ScreenHunter_20 Feb. 14 12.19

Now move it back to NYCCRNODE1.  We should now be able to see that the Majority Node Set is configured correctly.  On NYCCRNODE1, issue the command: Cluster Res “Majority Node Set” /priv

ScreenHunter_21 Feb. 14 12.21

Notice how the MNSFileShare is set to the correct share?  We are all set.

This concludes part 2 of the series.  Next article, we are going to set up the Transport Dumpster on the Hub Transport servers, and begin installing Exchange!

Installing a Continuous Copy Replication or CCR Cluster Part 1…

Uncategorized

 

In Exchange 2003, we were given a single high availability model to follow, clustering.  In 2003, you created what was called an “Exchange Virtual Server” or EVS, that consisted of a number of “nodes” or servers, that presented a singular "server” to the clients to connect to.

Essentially you would have two separate servers, attached to a single copy of the Exchange files.  This is made possible through the use of a SAN, that allows both physical servers to “see” the same database files.  The availability this would allow would be a typical Active/Passive situation, one node is Active, meaning it has control of the EVS and presents itself as the Exchange server the clients connect to, and one is passive, not doing anything.

If the active node were to fail, such as a blue screen, or someone accidently pulled the power plug, the passive node would detect that failure, and assume the role of the EVS, and mount the database’s and continue servicing clients.  There would be a time gap where the database’s were unavailable.  This would depend on the amount of storage groups and database’s, but typically would take about 30 seconds to 2 minutes before services were restored.  A client in cached mode would never even know there was a failure.

In Exchange 2007, this type of cluster is still available, it’s known as a Single Copy Cluster (SCC).  Exchange 2007 also introduced a new type of cluster, called a Continuous Copy Replication Cluster (CCR).  Also to note, Microsoft has changed the name of the EVS to CMS (Clustered Mailbox Server).

What is the difference?  Well, lets look at the diagrams below:

Cluster

On the left we have a SCC, note how there is one copy of the Exchange files.  The two separate physical machines, Node1.domain.test and Node2.domain.test, are both part of the cluster, and have access to the shared Exchange files through the use of a SAN or some type of approved shared storage.  In our scenario, one of the node’s, lets say Node1.domain.test, has control of the CMS known as MB01.domain.test.  Notice how the icon is a “ghost” server?  That’s because the server doesn’t physically exist.  Node1.domain.test presents itself as MB01.domain.test.  If Node1.domain.test fails, Node2.domain.test will take control of MB01.domain.test and present itself as the CMS.

Now, lets look at the right side of the screen.  We still have the two nodes, and the CMS.  But notice we have TWO copies of the Exchange files, one for each respective node.  We no longer have a single shared copy of the data, each node keeps its own copies.  In a CCR cluster, you have can a maximum of two total nodes in the cluster, and it has to be set up in an Active/Passive setup.

So, again, Node1.domain.test has control of the CMS MB01.domain.test.  If it fails, the role fails over to Node2.domain.test, which takes control of the CMS MB01.domain.test.  It is important to note that BOTH nodes ALWAYS have their respective databases mounted and operational, but only one has control of the CMS.

So now, the question is how do they keep both databases up to date?  The worst thing is to have database divergence, or a situation where the passive node is weeks behind the active node.  The way both are kept up to date is through log shipping and seeding.

Seeding, is the copying of the initial database.  If you have a 10 GB database on Node1, you “seed” or copy that database to the passive node so their copies are up to date.

You may notice that transactional log files are no longer 5 MB as they were in Exchange 2003, but are now 1 MB in size. The active node, after it has taken the data in a transaction log, and wrote that data to the actual database, will “ship” or copy that transaction log over to the passive node, so that the passive node can update it’s database is up to date, or close to that of the the active node.

This type of clustering is essentially a “Share Nothing Cluster”.  This means several things, most of which were either vulnerabilities with Single Copy Clusters, or a barrier to implementation:

  1. You now have multiple copies of the database.  In a SCC, if the database is corrupted, you HAVE to restore from backup.  There is no alternative copy to mount like a CCR.
  2. A SAN, or any type of shared storage is absolutely not required.  This means you can implement CCR utilizing direct attached storage
  3. You can take VSS or snapshot backups of the Passive node.  This allows you to offload any backup and verification jobs to the passive node, meaning you can take more backups with no impact to end users.  A successful backup on the passive node will force a truncation of the transaction logs on both the passive and active nodes!

There are still some requirements to implementing a CCR cluster, some of which are general rules of Microsoft Cluster Services, and some of Exchange:

  1. You can only have a single database per storage group to install a CCR cluster.  If you have a public folder database, it has to be in its own storage group, and the only public folder database in your organization.
  2. You still need a separate “heartbeat” network that the servers use to communicate with each other to detect if one of the nodes has failed.
  3. If using Windows Server 2003, the nodes have to be on the same network (Windows Server 2008 has added features for its Clustering software and can be used across subnets).
  4. A CCR node can only host the Mailbox server role.  This means that you need a minimum of three physical servers if you are going to install a CCR cluster.  Two nodes each part of the CCR, and than one more server hosting both the Client Access Server and Hub Transport Server roles.
  5. Paths for Exchange files, as well as drive letters and/or mount points should be identical on both nodes.
  6. OS’s should match patch level and version.

So that is a 10,000 Foot view of a CCR cluster.  In the next article, we will actually install the physical CCR cluster.  Stay tuned!!!

Overriding the Default Discovered Hub Transport Servers in an Active Directory Site

Uncategorized

 

In Exchange 2007, we know that email routing is directly tied to Active Directory Sites and Services.  A mailbox server in AD site A, will only be able to route using a Hub Transport server in the same AD site.  It can never fail over to a Hub Transport server out of it’s site, so we need to take care and build resiliency for our Hub Transport servers in each site.

Exchange 2007 is also smart, it will round robin load balance, automatically, between the 2 Hub Transport servers.  This means, that if one of the servers goes down, mail flow doesn’t stop, it simply fails over to the remaining Hub Transport server without issue.  There is no need to do anything in this case, all of this is done automatically behind the scenes…..but what if you don’t want it?

What if you need to isolate a HT server, for troubleshooting purposes?  Lets say you have three Exchange 2007 servers in your site, NYMB01, NYHT01 and NYHT02.  NYHT01 and NYHT02 are Hub Transport/Client Access Servers.  NYHT01 has been acting up, and you want to run some isolated troubleshooting steps on it, but that means it will still be up, but you don’t want it to be serving email.  Problem right? The MB server automatically will discover the HT server and use it for routing of email.  There is a way to stop this.

In ADSIEDIT, navigate to Configuration->Services->Organization Name-> Administrative Groups->Exchange Administrative Group->Servers.

ScreenHunter_02 Jan. 20 22.19

Now, right click on any Mailbox Role Server, and select properties.  Now search for a value named

msExchTransportSubmissionServerOverrideList

This is the value that lists which servers the MB server can use to route email.  By default, it will be blank:

ScreenHunter_03 Jan. 20 22.23

You can add distinguished names of the Hub Transport servers you want the MB server to only use, and this will stop it from discovering HT servers dynamically.  You can edit this value, or use a powershell command:

Set-MailboxServer –identity “NYMB01” –SubmissionServerOverrideList “NYHT01”

This will force the MB server, NYMB01, to only use NYHT01 as its HT server. To add multiple HT servers, just separate the values with a comma.

ScreenHunter_04 Jan. 20 22.26

Now look at the same value in AD:

ScreenHunter_05 Jan. 20 22.27

Now, NYMB01 will only use NYHT01 to route email.  Remember though, if NYHT01 happens to fail, your MB server will not be able to route email to any HT server that is NOT ON THE OVERRIDE list, so if you are going to do this, make sure it’s temporary, and you have redundancy. 

To change it back, simply clear this value of all specified servers!

The Page Must be Viewed Over a Secure Channel When Accessing a 2003 Mailbox Using a Client Access Server

Uncategorized

 

Exchange 2003 was very different in how you access Outlook Web Access than in Exchange 2007.  In 2003, the actual back end server, and more specifically STORE.EXE, was responsible for generating the OWA view.  In 2007, the Client Access Server is responsible for it.

During your migration, you will no doubt have a point where there are Client Access Servers now serving your internal or external OWA page, with users having mailboxes on 2003 servers. If you are a smaller installation, say you only had 1 or 2 Exchange 2003 servers, you may not have had 2003 Front End servers, and this would mean users would access the server directly for OWA. 

Since you are a good admin, and you wanted to encrypt and protect your users and their data, you have enabled Forms Based Authentication, which means you have deployed SSL. 

Now, when your users attempt to log into their OWA page, after inputting their user name in password in the 2007 forms based page, they receive the following message:

ScreenHunter_01 Jan. 03 02.45

This is because you have checked on the 2003 Back End server to require SSL in IIS, you most likely did it on the properties of the Default Web Site:

ScreenHunter_01 Jan. 03 02.46

To change this behavior, you need to disable “Require Secure Channel (SSL)” on the following virtual directories:

/Exchange

/ExchWeb

/Public

This is because the Client Access Service proxies your request to the 2003 Back End server in HTTP, not HTTPS. 

After you make this change, you will be able to access the OWA page for 2003 users through the CAS servers without issue.  Also, if you enable Integrated Windows Authentication on the /Exchange directory, this will stop your passwords from being sent in plain text if they try to access the OWA page directly from the 2003 server internally.  Still keep port 80 closed externally of course!

Mailbox Manager Policy’s in Exchange 2003

Uncategorized

 

Mailbox Management policies can be used through an Exchange Environment to manage the content of users folders.  For instance, you can set a policy to permanently delete all items in a users deleted items folder, older than 30 days, and over 1 MB in size.  What’s the benefit of this?  It allows you, as an administrator, to keep your system in check, and prevent users from storing 90 percent of their mailbox in their deleted items folders.

Okay so where is the downside?  I don’t want to say getting them to work, as starting the policies are very easy, but maintaining them can be a different story.  Their behavior, and application are not always so straightforward.  Let’s start with their theoretical application, and then go into troubleshooting their actual application.

Their are two types of Recipient Policies in Exchange 2003, E-Mail Address Policies, and Mailbox Management Policies.  E-Mail policies are used to define an email domain that the Exchange environment is allowed to accept email for, if it’s authoritative for it or not, and how to assign various email address policies to end users. 

ScreenHunter_01 Dec. 20 22.34

Here, this policy applies the @ponzeka.selfip.com email suffix as the primary, and the @ponzeka.test as an additional alias.  We can filter this out to certain users, to have their addresses applied successfully. 

Mailbox Management Policies are used to control content in users folders.  You can specify what to do, for a group of folders, based on age and size of the items. 

ScreenHunter_04 Dec. 20 22.39

In this policy, we have set the policy to move any item over 1 MB and over 30 days to the deleted items folder for all items except the Inbox, which we have set a tighter schedule of anything over 10 days. 

So now we know what both do.  We should also know this, each user or mailbox can have only ONE of each type of policy apply to them at a time.  This means, once the system finds an email address policy, it stops processing any others, and the same for mailbox management policies.  You can control how each policy applies to each user through filtering who the respective policy applies to, and the priority in which they are applied, the lowest value number has the highest priority, so 1 goes first, then 2 and so on.

This is usually the biggest troubleshooting steps administrators have, is that some rogue policy is applying.  Well, how do you figure it out?  It some cases it can be easy, where a policy that does a specific task, such as delete all email in all folders over 1 day old applies, then you can easily track it down (along with performing a couple of restores from backup!).  But in a big environment it can be much more difficult. 

We are going to use two tools to troubleshoot the application of mailbox management policies, ADSIEDIT and LDP, both of which are available with the Windows 2003 Support Tool Pack. 

Let me tell you the premise.  We are going to check a user, to see which policies he has applied to him/her, which will be represented by the policies object GUID or global unique identifier.  Then we are going to determine the GUID of the policy itself, and see if it applies or not. 

So, lets drill down to our user in ADSIEDIT.  We will be expanding the Domain Partition, finding our user (the layout matches that of Active Directory Users and Computers, as this is literally what Active Directory Users and Computers uses), and right click him/her, in our case the user is John Smith.

ScreenHunter_05 Dec. 20 22.53

Now, we want to scroll down until we find the attribute msExchPoliciesIncluded

ScreenHunter_06 Dec. 20 22.54

Edit the default string:

ScreenHunter_07 Dec. 20 22.55 ScreenHunter_08 Dec. 20 22.56

If you notice in the two screen shots, there is two lines.  Each line has a beginning GUID, a comma, and then a second GUID.  Well, that would mean there was 4 policies applied, did I just lie to you? 

No.  Remember, each user can have a single E-Mail address policy applied to them, and a single Mailbox Manager policy applied to them.  Each line represents one.  Why the four total GUID’s then? 

The first string value in my example is as follows:

{5D24E601-B570-4DD7-9ADE-3BA8FF018923},{3B6813EC-CE89-42BA-9442-D87D4AA30DBC}.

The last GUID in the string:

{3B6813EC-CE89-42BA-9442-D87D4AA30DBC} Is the GUID for Mailbox Management Policies.  It’s how the system identifies a particular policy, if it’s an E-Mail Address Policy or not.  That means, this 3B6813EC number is identifying:

{5D24E601-B570-4DD7-9ADE-3BA8FF018923}, as a mailbox management policy.

So the first value is the individual policies object GUID, and the second identifies it as a Mailbox Management Policy.

So the second string:

{7F68244A-07BA-4C0A-ACBE-74451F507700},{26491CFC-9E50-4857-861B-0CB8DF22B5D7}

Means that:

{26491CFC-9E50-4857-861B-0CB8DF22B5D7} is the GUID for how the system identifies an E-Mail Address policy.  This means it is identifying the 7F68244A GUID as an Email Address Policy.

So we have that cleared up.  Okay, lets now figure out which policy these values are!

Now, we could use ADSIEDIT for this, but its not fun, and this is why.  If we expand ADSIEDIT down to Configuration->Services->Microsoft Exchange –>Organization Name (by the way THIS part of the configuration partition, is what Exchange System Manager reports from).

Now click on the CN=Recipient Polices folder, and double click on one of your mailbox manager polices.

 ScreenHunter_09 Dec. 20 23.06

Now, navigate down to the objectGUID value and click edit, this is what you’ll get:

ScreenHunter_10 Dec. 20 23.07

This is the object GUID, however its not in the correct form.  Look closer:

ScreenHunter_11 Dec. 20 23.09

The first part of the string is suppose to be 5D24E601.  If we look, we have to count in 8 digits, and then read that last set left to right, go to the left, and do the same, and we have the same value.  Man, that absolutely is terrible.

There is an easier way, use LDP.exe.

Open the tool, and select connect.  It will ask you for a server to bind to, enter the FQDN of any domain controller.

ScreenHunter_12 Dec. 20 23.13

Now, press the “bind” button.  Enter in a Domain Admin account:

ScreenHunter_13 Dec. 20 23.14

Press okay again.  You should see the output pane on the right tell you successfully authenticated.

ScreenHunter_14 Dec. 20 23.15

Now go to “View-> Tree” and in the left hand pane, the forest root should be listed.

ScreenHunter_16 Dec. 20 23.16

Now, LDP.exe is not as nicely structured as ADSIEDIT, so we have to look more for where we need to go.  It also doesn’t show you if there are any child objects until you double click.  The path should be:

CN=Recipient Policies,CN=Ponzeka,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=ponzeka,DC=test

ScreenHunter_17 Dec. 20 23.20

Okay, in the right hand side, in the results pane, there will be a TON of junk.  Lets clear that.  You do this by selecting “Connection –> New”

Now, simply double click on the Mailbox Management Policy that you want:

ScreenHunter_19 Dec. 20 23.23

There it is, their is the object GUID in all it’s glory!  And, we now know that the value:

{5D24E601-B570-4DD7-9ADE-3BA8FF018923}, is typed to the Mailbox Management Policy “Mailbox Management Ponzeka.selfip.com”.  If we check the filtering of this policy, we note that it filters based on the membership of the group “Ponzeka.selfip.com Users”:

ScreenHunter_20 Dec. 20 23.25

And if we check the user, behold, he is a member of the group!

ScreenHunter_21 Dec. 20 23.26

Bam, that’s why he’s is getting the policy applied to him!  He is a member of a group he shouldn’t be!

In the next article I’m going to go over the behavior of Mailbox Management Policies in how they filter messages based on the criteria you set!

Using Resource Mailboxes in Exchange 2007 Continued…

Uncategorized

 

When I started the first article I never really intended this to be a post of “dreaded continuity”, but it has happened.

When we last spoke, we had set up a couple of Conference Room mailbox’s (Conference Room 20th Floor), and set a user (Paul Ponzeka) as the delegate.  We also set the conference room to Auto Accept meetings if the room was available.  Well that’s great right?  But what if we don’t want that?  What if we want the delegate to determine if that person can have the room?  You can do that as well!

What if you need to have all meeting requests forwarded to the delegate so they can approve?  We can do that very easily.  I have created a new Room Mailbox called “Conference Room 21st Floor”.  I have already assigned the user Paul Ponzeka as the delegate for it.  Now I need to set the mailbox to forward all the requests to it’s respective delegates.  To do this I run the following command in Exchange Management Shell:

Set-MailboxCalendarSettings <NameOfResourceMailbox> –AutomateProcessing AutoAccept –AllRequestInPolicy:$True –AllBookInPolicy:$False

Here is the command in action:

ScreenHunter_15 Dec. 08 20.27

The command was successful.  In the above command the Automate Processing Auto Accept string tells the mailbox to automatically book resources, the AllRequestInPolicy allows every user to send a request that has to be approved by a delegate.  AllBookInPolicy is set to false because this policy controls if the resource mailbox will automatically accept the invite the user sends if the resource is available.  This has to be false otherwise it overrides AllRequestIn. 

That’s the command line way, the other way is to access the mailbox through OWA 2007’s Exchange Impersonation feature.  Log into a mailbox that has access to the resource mailbox through OWA.  Click on the user name in the upper right hand tab and type in the name of the resource mailbox.

ScreenHunter_48 Dec. 09 22.15

Select the mailbox and hit open.  A new OWA page will open that is the Resource Mailbox’s.  Go to Options->Resource Settings

ScreenHunter_50 Dec. 09 22.17

Here you can set a multitude of settings.

ScreenHunter_51 Dec. 09 22.19

“These Users can schedule automatically if the resource is available”

This option means that you can specify AD groups or users that are able to schedule the room, and the mailbox will auto accept if it’s available.  You can use this to allow the Executives group to schedule this way.  The powershell equivalent to this would be:

Set-MailboxCalendarSettings ConferenceRoom21stFloor –AutomateProcessing AutoAccept –AllRequestInPolicy:$True –AllBookInPolicy:$False –BookInPolicy rraju

ScreenHunter_15 Dec. 08 20.27

This command states that the user who’s alias is “rraju” can book the Conference Room 21st Floor Mailbox without the delegate having to accept it.

The next option is “These Users Can Submit a Request for Manual Approval if the Resource is Available”.

This is the AllRequestInPolicy that we specified earlier.  If you want to change it to certain users, you would use the command RequestInPolicy <username> in the same syntax of the BookInPolicy as above.

The last option here is “These Users Can Schedule Automatically if the Resource is Available and Can Submit a Request for Manual Approval if the Resource is Unavailable”

To set this in the shell you must have both the BookInPolicy option and the RequestOutOfPolicy option set with the same users or groups.

The last real item of any significance is the Response Message.  Here you can specify a message to be sent to users when the request is processed:

ScreenHunter_52 Dec. 09 22.34

The only other option that I really like is –EnableResponseDetails:$true  option in the command shell.  This will provide a reason to the user for why their meeting was accepted or declined.  This way they know if the meeting was declined, it was because the room was booked and not that no one likes them!

See what happens when we try to book the room for a time that isn’t available!

ScreenHunter_54 Dec. 09 22.43

Using Resource Mailbox’s in Exchange 2007

Uncategorized

 

At one point or another in your Exchange administration, you will run into a situation where you have a conference room that someone needs to keep a schedule of.  Usually this is a receptionist, or an admin, and to avoid confusion, you must book the room through them.

In Exchange 2003, there was a bunch of ways to do this, but inevitable, I would always see some admin with 10 calendars in her mailbox, or in public folders trying to manage the rooms, and it get’s messy.

I was at a company where no one outside of the admin knew she was scheduling rooms like this, the company let her go and poof, all of the scheduling for the rooms went with it.

In Exchange 2007, there is a nice way to set up mailboxes for Conference Rooms or Equipment.  They are called, um, well, Room and Equipment Mailboxes!!

There are a total of four different types of mailboxes in Exchange 2007.  User Mailboxes, which are the normal type associated with a user.  Room Mailboxes, which are associated with a conference room.  Equipment Mailboxes, which are associated with mobile items like projectors, or laptops.  The last type is Linked Mailboxes.  These mailboxes are user mailboxes that are accessed by objects from a separate trusted forest.

We are focusing on Equipment and Room mailboxes, which generally do the same things.  The first thing we want to do is create a room mailbox called “Conference Room 20th Floor”.

To do this, open the Exchange Management Console, Expand “Recipient Configuration”, select the Mailbox node, and select “New Mailbox”.  From here, select the “Room Mailbox” option:

ScreenHunter_08 Dec. 08 20.09

From here its just like creating a regular user. 

ScreenHunter_09 Dec. 08 20.10

Finish it out, and you have your mailbox!  Notice the powershell code that would have performed the same action:

ScreenHunter_10 Dec. 08 20.11 

Now we have the mailbox.  The first thing we should note is that the user account associated with the mailbox is disabled:

ScreenHunter_11 Dec. 08 20.12 

Now we need to assign some delegates to it.  These will be the users responsible for managing the mailbox.  In our case, we are going to assign the delegate permission to the user “Paul A. Ponzeka”.  This has to be done through the Exchange Management Shell.  It’s done by running the command, Set-MailboxCalendarSettings <NameofRoomMailbox> –ResourceDelegates <alias of delegate>.

In our case this would be Set-MailboxCalendarSettings ConferenceRoom20thFloor –ResourceDelegates pponzeka.

ScreenHunter_12 Dec. 08 20.16

The command was accepted. (Thanks for all the pomp and circumstance Microsoft, Geez!)

Now, when we log on as Paul A. Ponzeka, we can open the Conference Room 20th Floor as a shared calendar.  Notice, we have an appointment on December 10th:

ScreenHunter_13 Dec. 08 20.19

Wait a second, what if I never checked?  The meeting still has to be accepted.  Well that’s annoying right?  Let’s change that.

The setting you have to change is called Auto Accept.  What this does is, when the resource mailbox receives a meeting request, it checks to see if the time marked is available.  If it is, it accepts the request and sends a confirmation.  If it isn’t, it declines the meeting and sends a cancellation.  Again, this can only be set through the Exchange Management Shell.  The command is Set-MailboxCalendarSettings <NameofRoomMailbox> –AutomateProcessing:AutoAccept.  In our case this command would be Set-MailboxCalendarSettings ConferenceRoom20thFloor –AutomateProcessing:AutoAccept

ScreenHunter_14 Dec. 08 20.24 

Again, big song and dance from Microsoft over the command being successful.  Now if we send another meeting request.  It will automatically send back the user an acceptance if the room is available!

Securing Your Exchange 2007 Environment Using Subject Alternative Name Certificates

Uncategorized

 

Security, Security, Security!!  As you may have noticed, a “big deal” in IT is security, not the least of which is related to email security.  Microsoft has made some great strides regarding the out of the box security of Exchange 2007 versus its predecessor.  First, you may have noticed that when you access OWA you are presented with a certificate.  Don’t remember installing one?  Exchange 2007 setup did when you installed it.  It creates a self signed certificate to secure OWA, as well as opportunistic TLS for SMTP transmissions, and all the Exchange Web Services.

As you no doubt already know, self signed certificates create a little bit of a problem.  They are un-trusted, and do not have the correct subject name for the resource.  You’ll find that there are three rules for certificate usage.

  1. The Certificate Authority has to be trusted.  This means that the company or computer that is issuing the certificate, is trusted by your PC and/or browser.  Third party certificate authority like Network Solutions and Go Daddy are generally trusted by most browsers. 
  2. The certificate has to be valid.  This means the time period, 11/01/2008 – 11/01/2009 must be valid.
  3. The certificate’s subject name has to be correct.  This is where most people get into trouble.  We will cover this in the article.

In our domain Ponzeka.test, we have a certificate authority NYDC01.ponzeka.test, that we will use to issue our certificates.  Since we will be accessing the Exchange end user environment from outside the domain, we need to get our PC to trust the CA.  Do this by installing the CA root certificate into your PC. 

We can access our Windows CA by navigating to http://nydc01/certsrv since we installed the web services with our CA. Select “download a CA certificate”

ScreenHunter_24 Dec. 03 21.48

ScreenHunter_26 Dec. 03 22.02

Save the .cer file to your desktop, and then run it, select Install Certificate, select Next all the way through.  When you get a warning message regarding installing the certificate, simply hit yes.

Your pc now trusts any certificate issued by this Certificate Authority!

Now, securing our environment.  Let’s talk a little about Subject Alternative Name (SAN) certificates.

In a certificate, a Subject Name is the name of the server that the certificate is issued to.  This also is the name the server is accessed by.  What do I mean? Consider the following diagram:

Network

Here, users on the internet access NYHT01.ponzeka.test as https://ponzeka.selfip.com/owa for OWA access.  What is the Subject Name?  Ponzeka.selfip.com is.  When you request the certificate for this server, you should request this name.  That way when users access it, their browser will match up the URL with the subject name that is listed in the certificate.  If it is off, your browser will prompt you with a warning.

Now, SAN certificates alleviate a problem.  What happens if a user internal to the ponzeka.test network tries to access the OWA page on NYHT01.ponzeka.test as https://nyht01.ponzeka.test/owa?  Their browser will return an error, because the subject name is incorrect.  This becomes important in Exchange 2007 because there are various web services that are accessed through Https internally, and if the certificates are wrong, users will constantly be prompted in outlook.  We will go over more of these later.

SAN certificates allow you to list multiple subject names in the certificate.  So you can list the external DNS name, internal DNS name, NetBIOS name, cluster DNS name, alias, and well you get the point.

For instance, remember from my previous post that we have joined NYHT01.ponzeka.test and NYHT02.ponzeka.test into an NLB cluster for the HT and CAS roles.  The NLB is accessed as mail.ponzeka.test.  We will add this as a subject name to our certificate request.  Let’s start with NYHT01.ponzeka.test. 

As noted before, when you install exchange, you get a self signed certificate for the server.  This is the one that comes with NYHT01:

ScreenHunter_27 Dec. 03 22.19

As you can see it was issued by NYHT01 to NYHT01.  If we click details, and navigate to Subject Alternative Name, these are the names that the certificate is valid for:

ScreenHunter_28 Dec. 03 22.20

NYHT01 (the NetBIOS name) and NYHT01.ponzeka.test (the DNS name). 

Also, on NYHT01 in the application log, you will find an error under MSExchangeTransport Transport Service Event ID 12014:

ScreenHunter_29 Dec. 03 22.21

This is stating that the system is unable to find a certificate for the domain name “mail.ponzeka.test”, which is the NLB name in this case.  Since it cannot find one, it cannot use the STARTTLS command in SMTP usage to encrypt the connection.  Let’s go about creating our SAN certificate request!

We need to do this request through the Exchange Management Shell.

You need to run the following command, it’s pretty long:

new-exchangecertificate –generaterequest -domainname ponzeka.selfip.com,nyht01,nyht01.ponzeka.test,mail.ponzeka.test -friendlyname "san certificate" -keysize 1024 -path c:sanrequest.txt -privatekeyexportable:$true

Now the blog format messes with the command, so here is the screen shot:

ScreenHunter_31 Dec. 03 22.37 

The –domainname option allows you to specify extra names for the server, as you can see we specified NYHT01, NYHT01.ponzeka.test, mail.ponzeka.test, and ponzeka.selfip.com.  It created a request that we can send to a CA at c:request.txt. 

Submit this request to the CA page at http://nydc01/certsrv, and select “request certificate”

ScreenHunter_32 Dec. 03 22.39

Select “Advanced Certificate Request” and then “Submit a certificate request by using a …”

Open your request and past all of the data into the box.

ScreenHunter_33 Dec. 03 22.41

Now hit the submit button:

ScreenHunter_34 Dec. 03 22.41

You will get a message stating that you need to way for an approval from an administrator.  If you open up the Certificate Services MMC, go to pending approvals, right click yours and hit Issue, you’ll be able to come back here and download your certificate!

ScreenHunter_35 Dec. 03 22.43

Download the certificate to your C drive as certificate.cer.

ScreenHunter_36 Dec. 03 22.43

Now we are ready to import the certificate.  Again this has to be done through the Exchange Management Shell.  Run the following command:

Import-ExchangeCertificate c:certificate.cer | Enable-ExchangeCertificate –Services IIS,SMTP,POP,IMAP

ScreenHunter_37 Dec. 03 22.46

Okay, what was that!!?!?!?  What I did in this command is called “piping”.  Since powershell, and thus the Exchange Management Shell is an object oriented language, I can take the output of one command (in this case Import-ExchangeCertificate c:certificate.cer) and make it the input of the next command (in this case Enable-ExchangeCertificate –services IIS,SMTP,POP,IMAP).  If I didn’t do this, I would have to run the first command.  It would list the thumbprint of the certificate, I would then have to use that in a separate command to enable it, which is quite cumbersome.  This way I do it all at once!  Also, as you can see I am enabling the certificate for use with IIS for OWA, SMTP, POP and IMAP services.  If you were using the Unified Messaging role you could use UM for that as well. Hit return.  You may get a warning asking you to overwrite the existing self signed certificate, hit yes.

ScreenHunter_38 Dec. 03 22.51

Okay, we are set, the certificate is installed! Now lets check it out.  Check out the details again, go to Subject Alternative Name and you’ll see the names we entered earlier:

ScreenHunter_41 Dec. 03 22.55

There are all the names that it will work for.  Now let’s test it out!

From https://NYHT01/owa:

ScreenHunter_39 Dec. 03 22.52 GOOD!

From https://PONZEKA.SELFIP.COM/owa:

ScreenHunter_40 Dec. 03 22.54 GOOD!

From https://MAIL.PONZEKA.TEST/owa:

ScreenHunter_42 Dec. 03 22.56 NO!!  Not Good!

What happened here?

Well, remember we have a NLB cluster between NYHT01 and NYHT02.  We must have hit NYHT02 during this session and it’s still using the old self signed certificate.  Follow the steps above to create a new SAN certificate for NYHT02, and no more warnings!!

In my next article I’ll show you how with certificates we can set up and use some of the exciting new Exchange Web Services with Outlook 2007, as well as go over some TLS over SMTP!!

Creating a Network Load Balanced Cluster for the Client Access Server and Hub Transport Server Roles Hosted on the Same Server

Uncategorized

 

In Exchange 2003, it was very common for admins to create a Network Load Balance (NLB) cluster out of their Front End servers.  The reason was that Front End Servers usually where their to provide internet access to internal resources.  Instead of having OWA URL’s like this:

owa.company.com

owa1.company.com

owa2.company.com

A company could have just owa.company.com, and create a NLB cluster of it’s internal Front End servers.  Since FE servers are essentially web servers in that their data is static, they lend themselves very well NLB clusters.

In Exchange 2007, the Front End server is replaced by the Client Access Server role.  It still makes sense to create a NLB cluster out of these roles because they server a similar purpose to Exchange 2003 Front End servers.  In order to save on hardware costs, many companies place their Hub Transport server roles on the same server as Client Access servers.

In Exchange 2007 RTM, it was supported to NLB the Client Access Server, even if the Hub Transport role was installed on the same server, you just couldn’t NLB the Hub Transport server. Now there are many arguments as to why you wouldnt need to load balance the HT role.  First, Mailbox servers, as long as they dont have a HT role installed, automatically load balance against any HT server in the same AD site, so why do you care?

One positive is if you use an application that can only specify a single smarthost as its manner of sending email.  If you specify one server, and that server goes down, you have a disruption to your application.  You could use Round Robin DNS, but it is not nearly as efficient as NLB, as it requires requests to fail often before it fails over.  There is no way that DNS will stop sending requests that the IP that’s down.  It will continue to send requests, wait for it to time out, wait for the client to send the request again and then send it to the working server.

Another positive is if you have gateway SMTP servers (sorry Microsoft, we don’t ALL use Edge Transport servers) that forward email to an internal smarthost?  Use the NLB cluster IP, and dont worry if one server has to go down for maintenance, expected or unexpected.  There will be no disruptions in mail flow.

In Exchange 2007 SP1, it is now supported to have a NLB between nodes that have both the CAS role and the HT role installed on them.

Here is our test environment:

  1. NYDC01.ponzeka.test (Domain Controller) – 10.3.1.102
  2. Exchange2003.ponzeka.test (Exch2003) – 10.3.1.101
  3. NYHT01.ponzeka.test (Exch2007 HT and CAS) – 10.3.1.104
  4. NYHT02.ponzeka.test (Exch2007 HT and CAS) – 10.3.1.105
  5. NYMB01.ponzeka.test (Exch2007 MB) – 10.3.1.103

You can create a NLB out of any version of Windows Server 2003, Enterprise Edition is not needed.

The first thing you need to do is actually install Exchange 2007 on all the servers.  Remember, the first role you should install should be the Client Access Server, then the Hub Transport, and finally the Mailbox Server.  In our case, we have an existing Exchange 2003 environment.  Current NYHT01 is the bridgehead server between the 2007 and 2003 routing groups:

ScreenHunter_02 Dec. 01 21.43

After we have installed all of Exchange 2007, updated it, done all our restarts, we are ready to install the NLB.  I will not go into the proper steps for the migration of an Exchange 2003 environment, as that has been covered by numerous people.  We are keeping the 2003 environment to show how it would interact with the NLB cluster.

The first thing we want to do is create the DNS alias for our NLB cluster, ours will be mail.ponzeka.test pointing to IP address 10.3.1.120.  This IP isn’t in use yet, but we will assign it to the IP of the cluster once its created.

ScreenHunter_03 Dec. 01 21.53

Now, there are two types of communications for NLB cluster, Unicast and Multicast.  In multicast the hearbeat is sent over the same NIC as production data with a changed MAC address, and in Unicast, there are two network adapters, one is dedicated to production, the other to the hearbeat network, we will use Unicast.

Assign NYHT01’s Heartbeat NIC the IP address 192.168.1.104 and a subnet of 255.255.255.0.  Leave the gateway and DNS blank.  Assign NYHT02’s heartbeat NIC 192.168.1.105.

ScreenHunter_04 Dec. 01 21.57

Make sure that each server can ping the other’s hearbeat IP address, this is what the servers will use to send information regarding their status in relation to the cluster over:

ScreenHunter_05 Dec. 01 22.01

Now on each servers, go to Control Panel –>Network Connections->Advanced->Advanced Settings.  Make sure the Production network is the highest in the binding order:

ScreenHunter_06 Dec. 01 22.02

Now we need to install Network Load Balancing on the heartbeat adapters.  On NYHT01, right click the Heartbeat connection and select properties.  Select the check box next to Network Load Balancing:

ScreenHunter_07 Dec. 01 22.04

Select Network Load Balancing and hit Properties. Under Cluster IP Config, the IP address is the one for the NLB cluster, which before in DNS we stated was 10.3.1.120 and the Full Internet (DNS) name, which is mail.ponzeka.test.

ScreenHunter_08 Dec. 01 22.08

Now select the Host Parameters Tab.  Here, enter in the IP address for the Heartbeat NIC for NYHT01, which is 192.168.1.104.

ScreenHunter_13 Dec. 01 22.51

Now select the Port Rules Tab.  Here is where you specify with ports the NLB cluster will listen, and react to.  As you can see by default it listens to EVERYTHING.  We don’t want that.  Remove the default rule.

Click Add, and uncheck the box “All”, enter in the Cluster IP address manually.  If you select ALL, in our case it accomplishes the same thing.  You can have multiple Cluster IP’s, and choose which cluster IP responds to what port. The other option you need to change is Affinity.  If the service is coming from the internal network, it should be Single.  If it’s originating from the internet, Class C.  If in our case, it will be doing both, we can set the ones that will be accessed by the internet to Class C, and others to internal.  In our case we will leave everything to Class C.  Your final screen should look like this:

ScreenHunter_10 Dec. 01 22.25

The ports are as follows:

  1. 25 – Default SMTP Port, should be allowed (HT)
  2. Port 80 – Default HTTP Port, should be allowed (CAS)
  3. Port 110 – Default POP3 Port, should be allowed (CAS)
  4. Port 143 – Default IMAP Port, should be allowed (CAS)
  5. Port 443 – Default HTTPS Port, should be allowed (CAS)
  6. Port 587 – Default SMTP with TLS Port, should be allowed (HT)
  7. Port 993 – Default Secure IMAP Port. should be allowed (CAS)
  8. Port 995 – Default Secure POP Port, should be allowed (CAS)
  9. Port 465 – Default Implicit SSL SMTP Port, should be disabled (CAS) as Exchange cannot use

After you hit OK, hit OK to the warning, and add the Cluster IP as a secondary IP to each cluster nodes heartbeat NIC:

ScreenHunter_14 Dec. 01 22.52

Hit OK, and you know have a NLB cluster working with one node, which makes NO SENSE!  We need to add the second node to the cluster.  We do this using Network Load Balancing Manager.

After loading, select “Connect to Existing” , enter the IP address of the cluster:

ScreenHunter_12 Dec. 01 22.36

To add the second node, right click mail.ponzeka.test and select add host to cluster:

ScreenHunter_15 Dec. 01 22.56

Select Next.  Make sure the priority number is unique in the cluster, select finish. All of the configurations we made on NYHT01, should now be made on NYHT02. Now the cluster is up!

There are some changes we need to make, specifically to the Hub Transport part of the cluster.  Open Exchange Management Console, navigate to Server Configuration –> Hub Transport, select NYHT01, and then right click Default NYHT01 and select properties.  on the Network tab, select “All Available IPv4 address” and select edit:

ScreenHunter_16 Dec. 01 23.05

Change it to an IP address, and specify the IP address of NYHT01, NOT THE CLUSTER.

ScreenHunter_17 Dec. 01 23.05

The default receive connector is used for communications between the Hub Transport servers themselves.  We do not want the NLB cluster dealing with this, as it is crucial for mail flow that each HT server participate in this process on its own.  Repeat this process for NYHT02.

Now you may ask, hey, I can no longer connect to the cluster on port 25, which defeats a BIG purpose of why I did this:

ScreenHunter_18 Dec. 01 23.10

What we are now going to do, is create a new receive connector on port 25, and have it listen on the cluster IP address.  You will need to do this for each node in the cluster.

Still under Server Configuration-> Hub Transport->NYHT01, click “Create new Receive Connector”

Name it NLB Relay, leave as custom:

ScreenHunter_19 Dec. 01 23.11

Change the IP address to only listen on the NLB cluster IP, and change the FQDN to that of the cluster, mail.ponzeka.test:

ScreenHunter_20 Dec. 01 23.12

Set the “receive mail from” according to your internet security settings, select next, and click new to create.  Repeat for NYHT02. Now we can telnet to the cluster on port 25:

ScreenHunter_21 Dec. 01 23.15

Notice how the SMTP banner reads mail.ponzeka.test the name of the NLB cluster.

Grant any required permissions for the receive connector by right clicking on it, selecting properties and navigating to the “Permission Group” tab.

Now lets see if the cluster actually works.  We need to stop NYHT01, and see if NYHT02 takes over.  I will shutdown NYHT01, and see if we can still telnet to the cluster.

With NYHT01 down, we are still able to telnet to the cluster:

ScreenHunter_22 Dec. 01 23.21 .

So we are pretty much all set.  Some words of advice though.  Outgoing emails, there isnt a need to load balance because you load balance HT servers on the Send Connector Source Server properties Tab.  This ensures that if one HT is down, its routed through the other one.  This feature is native to Exchange 2007 and need’s no additional configuration. 

For the Client Access Server, we see that if we access the OWA page at https://mail.ponzeka.test/owa, we are presented with the OWA page.  Keep in mind NYHT01 is still down:

ScreenHunter_23 Dec. 01 23.24

Since a NLB is used with static data, such as a web server, make sure you configure items identically on each CAS server, such as certificates.  You should try to use Subject Alternative Name (SAN) certificates whenever possible, but remember if your OWA is facing the internet, make sure that you got the subject name for the page internet users will be accessing it on.  The certificates will need to be requested by, imported on, and assigned by each CAS server.

Stay tuned for the next article which will cover the CAS part of the cluster in more depth.  I’ll show you how to create certificates for the CAS servers, and ensure they work across the cluster.

 

P.S. Lot of thanks to Henrik Walther over at www.msexchange.org for a lot of great info regarding the HT part of the clustering!  Great site, head on over and check it out.