Tuesday, September 30, 2014

FR (French) - Powershell 4.0 - Introduction - Move-ADObject

English - note to reader: as I'm bilingual, I wanted to write a series of blog posts about Active Directory management with Powershell (4.0) - but in French. I intend to continue blogging in English as well, perhaps with a hybrid migration to Exchange Online - Office 365 (after the staged migration that you can find in my previous posts).

In the title of the blog post, I'll add the prefix "FR (French)" to distinguish them from my posts in English.

Feel free to translate the page with Google Translate or make comments if you'd like me to clarify something (in French or in English).


***

Dans mes prochains postes de blogue, je voudrais me consacrer à la gestion d'Active Directory avec les applets de commande Powershell (version 4.0).

Un mot pour commencer : je vais utiliser le mot "applet" pour traduire "cmdlet" et je vais le mettre au masculin. D'abord, c'est un mot masculin. Ensuite, au Québec, on le met bien au masculin.

Pour les postes à venir, je vais supposer chez le lecteur à la fois une bonne connaissance d'Active Directory et de bonnes notions de Powershell. Autrement dit, je ne ferai de cours (de base) ni sur l'un ni sur l'autre. Si cela posait un problème pour le lecteur, je me permettrais de lui recommander d'autres sources pour une mise à niveau en ces matières.

En particulier, je vais me permettre, au nom de la concision, certains raccourcis que PowerShell admet du reste. Par exemple, je pourrais écrire "Select" au lieu de "Select-Object" ou bien "sl" au lieu de "Set-Location". Au lieu de taper "ProtectedFromAccidentalDeletion" après le applet Format-List (abrégé en "fl"), je pourrais écrire *protect*.

***

Il a fallu un moment de réflexion avant de décider comment j'allais organiser les postes. En effet, certains applets comme Get-ADUser, Get-ADGroup, et Get-ADComputer ne s'appliquent qu'aux utilisateurs, aux groupes et aux ordinateurs respectivement. D'autres, comme Move-ADObject ou Rename-ADObject, peuvent agir sur plusieurs types d'objets différents.

C'est au second genre de applets que mes premiers postes seront consacrés. Ensuite, je verrai les applets spécifiques aux utilisateurs, aux groupes et aux ordinateurs, etc..

Il est à remarquer que certaines tâches peuvent s'accomplir soit avec les applets Get-ADObject, Set-ADObject, New-ADObject, etc., soit avec les applets spécifiques à un objet particulier comme Get-ADUser, Set-ADGroup ou New-ADComputer.


Dans le premier cas, il faut préciser le type d'objet avec un paramètre, par exemple:

New-ADObject -Type Computer -Name PC1 (etc.)


Dans le second cas, l'applet désigne le type d'objet et il n'y a aucune raison de le préciser encore avec le paramètre -Type, par exemple:

New-ADComputer -Name PC1 -SamAccountName PC1


Je fais le choix de me concentrer sur les applets *-ADObject pour lesquels il n'y a pas d'équivalent parmi les applets spécifiques à un objet.

Nous commencerons par Move-ADObject




1er exemple: déplacer un utilisateur


Nous avons deux options :

PS C:\> Get-ADUser Aisha.Bhari | Move-ADObject -targetPath "ou=Berlin,dc=mynet,dc=lan"

ou...

PS C:\> Move-ADObject "cn=Aisha.Bhari,ou=Madrid,dc=mynet,dc=lan" -targetPath "ou=Berlin,dc=mynet,dc=lan"

Au contraire, ceci ne marche pas:

PS C:\> Move-ADObject Aisha.Bhari -targetPath "ou=Berlin,dc=mynet,dc=lan"
Move-ADObject : Cannot find an object with identity: 'Aisha.Bhari' under: 'DC=mynet,DC=lan'. [...]


Astuce: Il faut employer le nom distingué (DN) si nous voulons utiliser Move-ADObject d'emblée (au lieu de recourir à Get-ADObject en premier).



2ème exemple: déplacer un groupe


Peu importe le type d'objet, la syntaxe est toujours la même :

PS C:\> Get-ADGroup Accounting | Move-ADObject -targetpath "ou=Madrid,dc=mynet,dc=lan"

PS C:\> Move-ADObject "cn=Accounting,ou=Berlin,dc=mynet,dc=lan" -targetpath "ou=Madrid,dc=mynet,dc=lan"

Et encore une fois, nous avons besoin d'indiquer l'objet par son nom distingué (DN) si nous voulons utiliser la cmdlet Move-ADObject sans mettre l'applet Get-ADObject en premier. Ceci ne marche pas:

PS C:\> Move-ADObject Accounting -targetpath "ou=Madrid,dc=mynet,dc=lan"
Move-ADObject : Cannot find an object with identity: 'Accounting' under: 'DC=mynet,DC=lan'. [...]



3ème et dernier exemple: déplacer un ordinateur


PS C:\> Get-ADComputer PC5 | Move-ADObject -targetpath "OU=madrid,DC=mynet,DC=lan"

PS C:\> Move-ADObject CN=PC5,OU=Berlin,DC=mynet,DC=lan -targetpath "OU=madrid,DC=mynet,DC=lan"


Commentaire de la fin :

A mon avis, il est plus efficace d'utiliser Get-ADOject en premier, pour désigner l'objet, et ensuite, de passer l'objet à Move-ADObject avec le signe | ("pipeline") au lieu de taper tout le nom distingué. 


Tuesday, September 23, 2014

Exchange 2010 - High Availability - Client Access and Hub Transport roles - example of the KEMP VLM-200

The DAG is only part of high availability. It only provides this functionality to the mailbox (MB or MBX) server role. We must use other methods to provide high availability for the Client Access (CA or CAS) and Hub Transport (HT) roles.

The recommended option is to use a "load balancer". Besides distributing the load between two or more Exchange servers, it is "aware" of the availability (or non-availability) of the Exchange services (HTTPS, SMTP) and can redirect clients to another server as needed.

Let's imagine we have two servers with the CA, HT and MB roles: Svr1 and Svr2. These two servers are part of a DAG. If Svr1 holds an active copy of a database (that is part of the DAG) and if the server fails, the passive copy of the database on Svr2 will become active.

But what about client access?

How will clients connected to Svr1 know where to reconnect? And what about new clients that have yet to connect? How will they know to connect to Svr2 instead of Svr1?

The load balancer takes the "pulse" of the Exchange servers and when one fails, it directs new clients to the other server (Svr2 in our case) and redirects current clients to the other server as well.

Let's try to see how this functions in reality.


The KEMP VLM-200 virtual load balancer

I'll use a KEMP VLM-200 installed in ESXi 5.1. The installation of the VLM (not to mention the installation of ESXi) is beyond the scope of this post. However, I will say, in summary, that it is a matter of downloading a file from the KEMP website (that's www.kemptechnologies.com - not just kemp.com) and importing the .ovf file in ESXi. Rest assured, if you prefer Hyper-V, there is a version for this hypervisor and some others as well.

When we start the VLM-200 in ESXi, there's a bunch of command line information that displays and then a command prompt. The device can probably be configured at the command line but there is a much more user-friendly web interface. The IP address (DHCP assigned) is indicated among the command line information.

Note: use the DHCP assigned IP address indicated to connect to the web interface.

I want to concentrate on the configuration and use of the load balancer for Exchange so I'll go quickly here. If you want to use a KEMP load balancer I would recommned you contact them for assistance. In any case, you will have to contact them for a license. You cannot go beyond the "home page" without one. Once the license is entered (there are various options for this: online, offline, legacy... I will not detail them all here), we are prompted to logon and change our password.

Notes:

  • You can request a 30 day trial license.
  • The default username and password were provided by KEMP in an email.


Now I'm in and can start the configuration.

I'm most interested in the first Ethernet interface (eth0), the hostname, the DNS configuration and the default gateway. We can see these options on the menu to the left.



This is where you would configure the IP address of the first network interface (eth0):


I'll make the IP address 10.0.0.27 with a /8 or 255.0.0.0 subnet mask.

This is the IP address I will use from now on to access and configure the virtual load balancer.

Note: the connection uses HTTPS (port 443) so remember to type the URL like this:

https://10.0.0.27

If you are prompted about the web site's certificate not being trusted, you can ignore the warning - at least for the time being.



Templates for Exchange 2010

I could attempt to configure the VLM-200 for Exchange manually, setting by setting.

Fortunately, there are templates that prepare much of the configuration behind the scenes.

Just as we downloaded the virtual image for the VLM-200 from the KEMP technologies website, we can download templates that facilitate the configuration of Exchange 2010, of Exchange 2013 and a multitude of other server applications.

So I download the template for Exchange 2010 (contact support if you need assistance locating these templates - I found them in the Resources | Documentation section).

Note: the name of the template file is "Exchange2010Core.tmpl".

To import the template, we go to the "Manage Templates" link on the menu to the left (under Virtual Services):




We then browse to the downloaded template and import:





Now we have the following templates to work with:


Yes, that may be difficult to read. So I'll indicate the names of the templates here:
  • Exchange 2010 HTTPS: for access methods using HTTPS (autodiscover, OWA, Outlook Anywhere, ActiveSync, EWS, ECP).
  • Exchange 2010 HTTPS Offloaded: same as above except SSL connections terminate at the load balancer, Essentially, the load balancer manages SSL encryption of client connections and can, optionally, re-encrypt connections to the Exchange servers.
  • Exchange 2010 MAPI: these are Outlook connections.
  • Exchange 2010 SMTP: this is mail traffic to and from the Hub Transport servers (that may also hold other roles as well).


Configuration of services

In fact, we have to accomplish two tasks:

  1. Direct client access and hub transport traffic to the appropriate load balancer IP address (some services may have a distinct IP address) either with the IP address itself or via DNS. In particular, we want to point the CAS Array DNS record to an IP address of the load balancer. Incoming SMTP traffic should also be directed to the load balancer.
  2. Configure the services themselves (HTTPS access, MAPI access, SMTP traffic). We can do this manually or use the templates mentioned earlier. I will use the templates. At this time, we will designate the Exchange 2010 servers to which the load balancer will forward client access connections and SMTP traffic


Hub Transport (SMTP)

First, I'll configure high availability for the Hub Transport rule.

I'll start from the exterior (perimeter firewall) - and finish with the SMTP service configuration.

Inbound SMTP traffic is directed to my perimeter firewall using the MX and A records configured in what I will call "external DNS". We would manage this in the interface provided by our domain registrar or possibly a service like NO-IP. In my case, this has already been configured, like this:
  • The MX records points to the A record.
  • The A record points to the external IP address of my firewall.
The firewall performs what is known as "1 to 1 NAT" which redirects SMTP traffic for the external IP address of my firewall to the internal IP address of one of the Hub Transport (HT) servers.

So now we have to adjust the 1 to 1 NAT settings in the firewall so SMTP traffic is directed to the IP address of the load balancer instead of the IP address of one of the HT servers.

I have a Cisco ASA 5500 series firewall. The procedure would be similar, but not identical, on other devices. We have several choices for the interface: CLI (command line), ASDM (ASA Security Device Manager) or even CSM (Cisco Security Manager). I will use the ASDM (GUI) interface.

Note: I will simply show how to adjust the existing 1 to 1 NAT rule (and not how to configure new 1 to 1 NAT rules).

In the Cisco ASA, we create "NAT Rules" (and "Access Rules" for that matter) with "Network Objects". In my case, I have a network object that represents the current target for SMTP traffic, one of the Exchange 2010 servers with IP address 10.0.0.23. I'll edit the network object so the IP address to which SMTP traffic is directed now designates the load balancer :



10.0.0.28? Not 10.0.0.27?

Besides the IP address of the physical interface(s), load balancers usually have several "virtual IP addresses" (VIP) that correspond with the "virtual services" provided. Each service has an unique IP address / port combination.

In my network, 10.0.0.28 (port 25) is the VIP that I will configure for the SMTP service.

Next, we'll configure the SMTP service.

At the Main Menu, we navigate to "Virtual Services" and then "Add New":


We then specify the parameters for that service as follows:



Some comments....
  • The virtual (IP) address is 10.0.0.28.
  • The port is 25 (for SMTP - with TCP for the protocol).
  • The service name is optional but I'll call it "SMTP - HT role".
  • Among the templates imported previously, I'll select the "Exchange 2010 SMTP" template.
This configures the appropriate settings automatically.

We still need to designate the "real servers", in our case the Exchange 2010 Hub Transport servers for which we are load-balancing.

On the same page, there are a number of other sections (that we do not need to explore for basic configuration) and then "Real Servers". We configure them as follows:


Once again, for basic functionality, we can use the settings shown above (some may be default settings and already present). In my case, I enter the IP address of my first Exchange 2010 server (EX13-1) - 10.0.0.23 - and then (screenshot not shown) for the second Exchange 2010 server, 10.0.0.24.


Client Access (Outlook - MAPI)

For Client Access, we would configure the ASA 5500 as above, except that we would modify the rule for HTTPS (port 443). This would cover services such as OWA, Outlook Anywhere and ActiveSync.

As for Outlook, we need to adjust the DNS record for the CAS Array. Until now, that DNS record pointed to EX13-1, one of the Exchange 2010 servers, at IP address 10.0.0.23. I need to change the record so it points to the load balancer:




As for the MAPI service, we would select the "Exchange 2010 MAPI" template and configure the settings as follows:



We would then indicate the "real servers" as we did for the SMTP service.

Lastly, in my case, we would configure the Exchange 2010 HTTPS service as we did for the two previous services except that we would choose the corresponding "Exchange 2010 HTTPS" template and use port 443. We can use the same IP address since the port is different from port 25 (SMTP) and port * (MAPI).

Note: why not port 135? I'm not sure. If I recall correctly, that is how the template configured the service. 

***

I realize my post does not cover all aspects of the configuration of a VLM-200 load balancer and does not demonstrate each procedure in step-by-step detail. It was meant as a overview with screenshots illustrating some of the key points. Morever, it does not address more advanced subjects such as SSL offloading or the different types of affinity.

For those interested in more details, or perhaps other perspectives on the KEMP load balancers, I would consult the sources below. Andy Grogan and Paul Cunningham have presented the KEMP VLM-100 which is an earlier version of the VLM-200 load balancer:

http://www.telnetport25.com/2012/06/review-of-the-kemp-technologies-loadmaster-vlm-1000/

http://exchangeserverpro.com/kemp-vlm-100-exchange-2010-load-balancer/

You can also register at the KEMP website to access documentation and watch instructional videos.

Exchange 2010 - DAG (Database Availability Group) - Part 3 - "Status - Fail" - suspend and reseed

The Problem

The mailbox databases in a DAG can be in a failed state (for whatever reason). If we compare the Get-MailboxCopyStatus output for two DAG partners, we may see something like this:

Get-MailboxDatabaseCopyStatus DB1\EX13-1 | fl Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState

Name                 : DB1\EX13-1
Status               : Mounted
CopyQueueLength      : 0
ReplayQueueLength    : 0
ContentIndexState    : Healthy

Get-MailboxDatabaseCopyStatus DB1\EX13-2 | fl Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState

Name                 : DB1\EX13-2
Status               : Failed
CopyQueueLength      : 3
ReplayQueueLength    : 0
ContentIndexState    : Healthy


The "ContentIndexState" for both copies is "Healthy" but the status for database copy DB1\EX13-2 is "Failed".  We can see the status for the mounted database in the output for DB1\EXCH-1 ("Mounted").

I do not have a screenshot of this particular situation but in the EMC, at the Organization level, Mailbox (role) section, we would see what we see here, except that the Copy Status for DB1 on the EX13-2 server would be "Failed" instead of Healthy.




The Solution

We have to reseed the database with the data from a healthy copy.

But first, we must suspend replication (no reseed possible if replication is not suspended).

So we suspend replication with this command:

[PS] C:\>Suspend-MailboxDatabaseCopy DB1\EX13-2

This would produce the same result in the EMC:




That operation changes the copy status of the database:

[PS] C:\>Get-MailboxDatabaseCopyStatus DB1\EX13-2 | fl Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState

Name                 : DB1\EX13-2
Status               : FailedAndSuspended
CopyQueueLength      : 3
ReplayQueueLength   : 0
ContentIndexState    : Failed


We then update (or reseed) the failed database copy with the data from a good copy:

[PS] C:\>Update-MailboxDatabaseCopy DB1\EX13-2 -DeleteExistingFiles

Note: we have to overwrite the existing files, if present.

Here is the EMC equivalent:



We can select various options on this screen:



We click on "Update" to start the operation.

Note: heed the warning about the possible duration of the reseeding operation which could require several hours for larger databases.

In my case, the update process requires less than a minute (small test databases).

This is the result (to be compared to the original output above):


[PS] C:\>Get-MailboxDatabaseCopyStatus | fl Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState

Name                 : DB1\EX13-1
Status               : Mounted
CopyQueueLength      : 0
ReplayQueueLength   : 0
ContentIndexState    : Healthy

[PS] C:\>Get-MailboxDatabaseCopyStatus DB1\EX13-2 | fl Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState

Name                 : DB1\EX13-2
Status               : Healthy
CopyQueueLength      : 0
ReplayQueueLength   : 0
ContentIndexState    : Healthy




Thursday, September 18, 2014

Exchange 2010 - DAG (Database Availability Group) - Part 2 - Switchovers

In a Database Availability Group (DAG), there can be two or more copies of a mailbox database (the maximum number of copies is sixteen). One of these copies is the "active" copy, used by clients to perform daily email and calendaring tasks, and the other copies are "passive", held in reserve in case the active copy fails.

If the active copy becomes unavailable (because the server hosting it is out of service or something happens to the database itself), the DAG will perform a "fail-over". Once the DAG determines that the active copy is indeed unavailable for client use, it will activate the passive copy.

There are also situations when we would want to activate the passive copy manually. One common example would be for server maintenance that requires a reboot, like when we install Windows updates. In this case, we call the operation a "switch-over".

Note: some use the term "*-over" to designate fail-overs and switch-overs in general. The term is prononced "star-over".

This allows us to make the passive copy active (and vice versa) so we can perform maintenance on the server in question while continuing to provide messaging services to our users.

We have at least three methods to perform a switch-over:
  1. With the Exchange Management Console (EMC)
  2. With the Exchange Management Shell (EMS)
  3. With the StartDagServerMaintenance.ps1 script
Note: we use the StopDagServerMaintenance.ps1 script when maintenance is finished.

The last method is preferred because it can not only change the active copy of multiple mailbox databases but also the activation status of the servers and the holder of the "Primary Active Manager" role. We'll see those details later.

Otherwise, the first two methods are prefectly valid if we want to make the passive copy of the database active (and vice versa). Of course, if there are multiple copies, we would say "make one of the passive copies active".


EMC method

In my first example, we have two Exchange 2010 servers in our DAG: EX13-1 and EX13-2.

Currently, EX13-2 holds the active copy of the database "DB1":




The active copy is designated by the term "Mounted". The passive copy is not mounted but "Healthy". In other terms, it is ready for use, or ready to be mounted if necessary.



To move the active copy to Mailbox Server EX13-1, we right-click on database DB1 and select the menu option "Move Active Mailbox Database":




We must select the target server (browse to locate that server):


Note: unless we have reasons to do otherwise, we can leave the "mount dial setting" at None. Please refer to online sources if you are interested in the other options for this setting.

Managing Database Availability Groups (Exchange 2010)

Managing Database Availability Groups (Exchange 2013)

We click on Next (or Finish) to complete the operation:



Now the active database is "Mounted" on EX13-1:




EMS method

Now we'll perform the same operation using the Exchange Management Shell, moving the active copy of the database from EX13-1 to EX13-2. This one line cmdlet is all that is required:

[PS] C:\>Move-ActiveMailboxDatabase DB1 -ActivateOnServer EX13-2 -MountDialOverride:None


The result? Now the active copy of database DB1 is held by EX13-1. This change displays as shown below:



In case the small print is difficult to read, the status of the database copy is now "Mounted" on EX13-1 and "Healthy" on EX13-2.



StartDagServerMaintenance.ps1 script

The methods above simply change the status of the database(s) from active to passive and vice versa. They do not change the server holding the Primary Active Manager role and they do not block the passive databases from becoming active, which we would want to prevent if we were performing maintenance on the server in question.

As explained in the Technet document Managing Database Availability Groups (Exchange 2010) , this script performs the following tasks:
  1. Makes all active databases hosted on the DAG member in question passive - and the passive copy on other DAG members active .
  2. If the DAG member currently holds the "Primary Active Manager" (PAM) role, the script transfers this role to another DAG member.
  3. Pauses the node (the DAG member in question) so it cannot become the PAM during maintenance (which we want to avoid).
  4. Sets the value of the DatabaseCopyAutoActivationPolicy parameter on the DAG member to Blocked.
  5. Runs Suspend-MailboxDatabaseCopy to suspend each database copy hosted on the DAG member for activation.

In summary, the script "moves" active database copies to other DAG members, moves the PAM role, and prevents active database copies or cluster roles (like the PAM role) from being "moved" back to the DAG member that is undergoing maintenance.

Note: I have placed quotes around the word "move" because the active copy of the database is not really moved. The content of the database marked active is constantly replicated in the background to the copies marked passive. When we make the active copy passive, and one of the passive copies active, we are simply changing the status of the copies rather than moving entire databases from server to server.


The script is located in the following location:

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>.\StartDagServerMaintenance.ps1

When you attempt to execute the script, remember to type "." and "\" just before the name of the script itself.

We will be prompted for the name of the DAG member we wish to place in maintenance mode:

cmdlet StartDagServerMaintenance.ps1 at command pipeline position 1
Supply values for the following parameters:
serverName:

I simply enter: EX13-1.

If we want, we can verify that the script has performed at least some of the tasks listed above.

For example, the database should be in the "Healthy" state on the server we designated at the prompt above, and "Mounted" on the server that previously held the passive copy of the database:





We can also see this with the EMS:

[PS] C:\>Get-MailboxDatabaseCopyStatus DB1\EX13-2 | fl Name,Status

Name               : DB1\EX13-2
Status               : Mounted

[PS] C:\>Get-MailboxDatabaseCopyStatus DB1\EX13-1 | fl Name,Status

Name               : DB1\EX13-1
Status               : Healthy


The script is also supposed to prevent the targeted server from holding active copies of mailbox databases (we would not want it to attempt to activate a database during maintenance). We can observe those results with this cmdlet:

[PS] C:\>Get-MailboxServer | select name,*activation* | ft -auto

Name   DatabaseCopyAutoActivationPolicy
----   --------------------------------
EX13-1                            Blocked
EX13-2                     Unrestricted


The policy is "Blocked" for EX13-1, which is the correct setting for a server undergoing maintenance.

Once we have completed maintenance (installed Windows updates, etc.), we can execute the StopDagServerMaintenance.ps1 script:

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>.\StopDagServerMaintenance.ps1

As previously, we have to designate the server that we intend to bring out of maintenance mode. In our case, it is obvious and we may wonder why we have to take to trouble of specifying this. In other environments, however, there could be up to sixteen DAG members and possibly more than one in maintenance mode at any given time.

Lastly, we can verify that the server in question is out of maintenance mode using the methods presented above.

Note: even after the server leaves maintenance mode, its mailbox databases will not necessarily become active (mounted) again. The copy on the other server could remain the active copy or a copy on yet another server could become the active copy.



Saturday, September 6, 2014

Exchange 2010 - DAG (Database Availability Group) - Part 1 - Configuration (initial)

There is much existing documentation on Database Availability Groups already, so my objective is not to provide information that is 100% original but rather outline the procedure that I followed to configure this form of high availability in my test network.

In its most basic form, a DAG requires two Exchange servers and at least one more server hosting the "File Share Witness". The two Exchange servers can also hold the CAS and HT roles in addition to the MBX role. In this case, however, they cannot use Windows NLB to provide high availability for the other roles. In my network, I'll use a virtual load balancer for these roles (subject of another blog post). 


Network Configuration

We can either use the existing NIC on each of the two Exchange servers, configured with the usual network settings (IP address, subnet mask, default gateway and DNS servers) or add a NIC and configure the second NIC specifically for DAG replication traffic.

Yes, in a DAG, there are several types of network traffic.

  • MAPI traffic = users accessing their mailbox via Outlook.
  • Replication traffic = log files of a primary (active) copy of a given database being copied to the server(s) holding the passive copy of the database. In our case, there is a single passive copy. There could be up to 16 copies.

There is also "heartbeat" traffic by which the DAG members determine which partners are online and available (or not).

If we want to use separate NICs for MAPI traffic and replication traffic, we should have two NICs in each of the servers as shown in the illustration below. We can name them what we want but the names must be identical. In my case, I've named the MAPI NIC "MAPI" and the replication NIC "REPL". It makes sense to use descriptive names so you can distinguish the two NICs.



We configure the MAPI NIC as follows:





So for the MAPI NIC we leave all items checked and besides an IP address and subnet mask, we designate a default gateway and a DNS server.

Note: the IP addresses are just examples, of course.

The replication NIC is different in this respect. We uncheck the top three items and do not designate a default gateway or DNS server:




There is one more important setting not shown in the screenshot. In advanced properties, we should go to the DNS tab and uncheck this option:

"Register this connection’s addresses in DNS"

Lastly, we should adjust the "binding order" so the MAPI NIC is above the replication NIC:



Note: among the menu options (File, Edit, View...) there should be an "Advanced" option. Select this and then "Advanced Settings". Press on Alt if these menu options do not appear toward the upper left corner of the window.

One word on IPv6.

My research leads me to believe that it should remain enabled on both NICs. I believe this is the current Microsoft recommendation. In the past, it seems that there were problems with IPv6 in Exchange 2007 (?) and disabling it was the solution. Any such problems should have been corrected since. On the other hand, I have read several sources that caution against disabling IPv6, especially when installing Exchange 2010.

If it is necessary to disable IPv6, it is not enough to uncheck the item in the NIC properties. The administrator must also disable it in the registry. Please consult the appropriate documentation online if you determine that this option is necessary.


Database paths

They must be identical on each of the DAG members. So if the database to be added to the DAG is located at C:\DB1\DB1.edb on DAG server 1, the same path must be used on DAG server 2 (and 3, etc.). In fact, outside a test environment, we would probably never store the mailbox databases on the same volume as the operating system.

Here is an example of how we could set the database paths identically on both servers:




Note: the "A" is there simply so these folders remain at the top of the folder list.

I have already created a database (with associated log files) on EX13-1. Later, we'll add that to the DAG.



File Share Witness (FSW)

Ideally, an additional HT server would be designated and in that case, no further configuration would be necessary. Since we are using a simple file server, we must add the "Exchange Trusted Subsystem" group to the local Administrators group of the file server.

Note: on a member server, we do this in "Computer Management".





Create the DAG

We can use the EMC or the EMS to create the DAG. I will use the latter.

There are three major steps in the creation of a DAG:

  1. The creation of the DAG itself
  2. Adding mailbox servers to the DAG
  3. Selecting mailbox databases that will be part of the DAG

So I'll start by creating the DAG itself.

I thought that all was ready but when I execute the following command...

[PS] C:\>New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer FSW1.mynet.lan -WitnessDirectory C:\FSW -DatabaseAvailabilityGroupIpAddresses 10.0.0.25

I already encounter an error:

WARNING: Unable to access file shares on witness server 'FSW1.mynet.lan'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: The network path was not found. The DAG is created but without the FSW. This must be corrected.

First, I know:

- I have added the Exchange Trusted Subsystem to the local administrators group
- I have added the File Server role.

However, observing the Windows Advanced Firewall settings, I note that none of the File Share rules are enabled.

We can enable them in at least two ways. In the basic Windows Firewall settings (Control panel), enable File and Printer Sharing or simply share a folder. I share an test folder and note that this action enables the File Server rules, notably those for SMB.

I could remove the DAG and start all over but this incident provides the opportunity to configure the FSW with the Set-DatabaseAvailability cmdlet:

[PS] C:\>Set-DatabaseAvailabilityGroup DAG1 -WitnessServer FSW1.mynet.lan -WitnessDirectory C:\FSW_DAG1

Even though the cmdlet completes successfully (no errors), the share may not appear immediately. Usually, we have to wait until servers are added.


Second, I have to add the mailbox servers that will be members of the DAG.

I encountered an error here as well, due to communication problems with the FSW server. For the sake of concision, I will not post all the troubleshooting. In the end, I had to execute this command on the FSW server:

PS C:\> Enable-PSRemoting

This is more or less the equivalent of the command winrm quickconfig and accomplishes the following:

    1. Starting or restarting (if already started) the WinRM service
    2. Setting the WinRM service type to auto start
    3. Creating a listener to accept requests on any IP address
    4. Enabling firewall exception for WS-Management traffic (for http only).

In any case, this allowed me to add servers to the DAG with these cmdlets:

PS] C:\>Add-DatabaseAvailabilityGroupServer DAG1 -MailboxServer EX13-1

[PS] C:\>Add-DatabaseAvailabilityGroupServer DAG1 -MailboxServer EX13-2


Finally, I can designate a mailbox database to be part of the DAG. This translates into the creation of a second copy of the database on the second server. Mailbox database "DB1" already exists on server EX13-1 where I created it. With the following cmdlet, a second copy will be created on server EX13-2:

[PS] C:\>Add-MailboxDatabaseCopy DB1 -MailboxServer EX13-2 -ActivationPreference 2


So we add a copy of mailbox database DB1 to mailbox server EX13-2 with an activation preference of 2. This means that the database will be active on EX13-1 unless something happens, in which case it will become active on EX13-2. If we have more DAG servers, the activation preference could be higher (3, 4, 5 ,etc.).

This concludes my first blog post on Database Availability Groups.


Wednesday, September 3, 2014

Outlook 2010 - Manage Outlook settings with Group Policy - Part 2 - Cached Mode, OSTs and OABs

Once we've installed the Office 2010 ADMX files, and created the GPO (please see Part 1), we can configure the settings that will regulate Outlook functionality.

In this example, I would like to prevent the use of cached Exchange mode which should translate into the absence of .ost and .oab files in the local user profile on the client machine.

Note: use of cached Exchange mode may be preferable in your environment. This example does not imply that, in general, it should be disabled. Each administrator should weigh the advantages and disadvantages of cached and online mode.

First, let's look at what the user profile would look like with cached Exchange mode enabled.




We have both a .ost file which is the byproduct of using cached Exchange mode (this is cached version of the mailbox) and a Offline Address Books folder which contains a set of .oab files that constitute the Offline Address Book.

How could we prevent the downloading of this data if we determined that to be appropriate for our environment?

I created a GPO named "Outlook 2010 settings".

We'll right-click on it (in the Group Policy Management Console - or GPMC) and navigate to the following location:

User Configuration | Policies | Administrative Templates | Microsoft Outlook 2010 | Account Settings | Exchange | Cached Exchange Mode

In the right pane, open the following setting:

"Use Cached Exchange Mode for new and existing Outlook profiles"

And select "Disabled":



The "Help" section  informs us that:



I also enabled the following setting one folder above:

"Do not allow an OST file to be created"



So my GPO has the following settings enabled (or disabled...) :


I then apply the GPO to the OU containing my test user and logon to a computer on which they do not have an existing profile.

Note: you may have to adjust the GPO order of application as well, for example:




If we go to the location previously indicated, we see that there is no OAB folder and no .ost file:



Likewise, if we look at the Exchange "Server Settings", we will see that "cached Exchange mode" is grayed out:




As for the OAB folder (and files), I did observe, in testing, that such a folder was not created by default (once the settings above are applied). However, I noticed that the user could still attempt to download the OAB manually. This will create the OAB folder:



However, we can ensure that the OAB is not downloaded with the following setting:

[...] Microsoft Outlook 2010 | Account Settings | Offline Address Book | Offline Address Book: Limit manual OAB downloads

Set the number of manual downloads to 0:



This is the result...

An error message for the user:




And even if the OAB folder is created, no .oab files are downloaded:



Tuesday, September 2, 2014

Outlook 2010 - Manage Outlook settings with Group Policy - Part 1 - the Office 2010 ADMX files

Researching aspects of Exchange "cached mode", versus "online mode", OST files and Offline Address Books (OAB), I wanted to test how these various elements could be managed by Group Policy.

What if, for example, we want to prevent users from creating .PST files, or using Exchange cached mode (which happens to be the default in Outlook)? This could be for security reasons. We may not want cached copies of the user's mailbox on laptops that could be stolen. Of course, encryption could offer some protection in this respect. However, we might simply want to eliminate this risk by preventing any form of email from being stored on the client machine from the start.

Until now, I had never managed Outlook with Group Policy although I was aware that it was possible. In the lines that follow, I'll configure a GPO (group policy object) to this effect. I will assume that the reader is familiar with Group Policy and in particular the "Group Policy Management Console" (GPMC). This means I may go straight to a GPO without explaining how to open the GPMC.

The first step was to download the Office 2010 ADMX files and the second, to add them to the "central store". If you do not know what ADMX files are, or what the central store is, I would invite you to refer to traditional and online sources to learn about these components of Group Policy. 



Download the Office 2010 template files (ADMX)

When I composed this blog post, the Office 2010 ADMX files could be downloaded from this location:


If the link is no longer valid when you read this, I would conduct an online search (with Bing or Google) to find the new location.

Please note that the Office Customization Tool is part of the download but is not necessary to configure the Office 2010 elements in Group Policy. There was also a choice between 32 bit and 64 bit templates. Select whatever is appropriate for your environment. In my test network, both Windows 7 (SP1) and Office 2010 (SP2) are 64 bit so I only downloaded those files. There is also an Excel file summarizing the different group policy settings. It can be downloaded for reference but is not necessary.

The executable file I downloaded was named "AdminTemplates_64". After "unblocking" it, I execute the file which creates a folder containing some subfolders and in particular the "ADMX" subfolder. This subfolder contains the Office 2010 templates I will import later.



Create the "Central Store"

Next, I must add these templates to the "central store".

But there's a problem... No central store was ever created in my test lab.

So I'll create one now - and show you how, which may be useful if you have not yet created one yourself.

First, using the Default Domain Policy as an example, let's see how we can tell if the central store is being used.



The print in the screenshot is small but the Administrative Templates - Policy Definitions are "retrieved from the local machine".

Of course, that's to be expected since we have not yet created the central store - which will actually take the form of a (sub)folder named "PolicyDefinitions".

We want to create this folder under the SYSVOL share (so it can be replicated to other domain controllers).

Note: the name for the folder should be "PolicyDefinitions" (no space).

Here is the exact path (please refer to the illustration as well):

C:\Windows\SYSVOL\sysvol\domain_name\Policies



There will already be subfolders present in the Policies folder. This is normal. These folders contain settings for existing Group Policies, the Default Domain policy and the Default Domain Controller policy in particular.

In this case, the folder will be empty because we just created it. However, there may already be files and folders inside. This would be the case if we created the central store earlier and populated it with the latest Group Policy templates (Windows 2012 R2 / Windows 8.1 at the time of this blog post). In that case, this is what we might see:



So we have the ADMX files that allow us to manage various Windows OS parameters as well as the language specific ADML files for management, contained in their respective folder. In this example, we have ADML files for US English in the "en-us" folder and for French in the "fr-fr" folder.

 If we close and reopen the GPMC, and examine the Default Domain policy again, we can verify that the administrative templates are now being retrieved from the "central store":



Please note the subfolders of the "Administrative Templates" folder. Once we copy the Office 2010 templates into the PolicyDefinitions folder (the next step), we'll see some more folders specific to Office 2010 components.



 Add the Office 2010 ADMX files to the Central Store

This step is a simple matter of copying the files created earlier into the PolicyDefinitions folder. We should then see the Office 2010 ADMX files among the other ADMX files, in this case (below) an Access 2010 ADMX file:




Note: copy the appropriate ADML files to the corresponding language folder.

In addition, if we open a GPO, we should see the Office 2010 templates:



There are even more Office 2010 templates under the User Configuration section, and among them "Microsoft Outlook 2010":



Now we are ready to create a new GPO that will allow us to manage Outlook settings.

I'll create the GPO (right-click on the "Group Policy Objects" folder and select New) and...



We'll see the specific settings to configure in my next blog post (Part 2).