RSS Subscription 167 Posts and 2,643 Comments

Blog Archives

Exchange 2007/2010 Connection Filtering and Transport Configuration

Connection Filtering Basics (Blocking Connection to the Server)

Many of you know what Connection Filtering is in Exchange. It allows you to control what IPs are allowed and what IPs are blocked.   Taking a look at the following image, we can see exactly what parts of Anti-Spam utilize the connection filtering agent.

In the following image, we can see in what order the anti-spam agents run.

If you utilize the IP Block List, if something is blocked, the connection dies there.  Let’s take a look at the IP Block in action and how the connecting server’s connection is terminated.  For starts, let’s take a look at the connecting machine’s IP.

Let’s make a telnet to the server on port 25.

We see the connection works just fine.  Now, let’s go add the client IP to the IP Block List. To do this, Select IP BlockListRight-Click > Select Properties > Click Add > Enter Client IP Address.

Now let’s try Telneting to the Server over port 25 again.

As we can see, we cannot communicate via port 25 to the SMTP Server anymore due to the connecting IP being on the IP Block List.

Connection Filtering and Non-Exchange SMTP Filtering Appliances/Servers

One of the big things here, is that Connection Filtering happens based on the last untrusted IP Address.  One of the biggest things that are overlooked when using the Exchange or Forefront Connection Filtering Agent is that it is very important for you to enter the trusted SMTP IP Addresses in your organization.

This will need to be done via your Hub Transport Server.  To modify the trusted SMTP IP Addresses in your organization, go to Organization Configuration > Hub Transport > Global Settings > Message Delivery.

It is very important when using Connection Filtering to enter ALL trusted IP Addresses that handle SMTP in the organization.  This includes any type of SMTP Appliance/Server that is sending traffic to Exchange.  This includes Ironport, Sendmail, Barracuda, etc…  The reason why is, the way Connection Filtering works, is that it looks at the sending server’s IP Address and does the lookup on that.  But, let’s say it’s the Edge Transport Server and it’s receiving mail from an Ironport.

Do you really want the Connection Filtering lookup to lookup the Ironport IP?  Of course not, Ironport is an internal server.  Connection filtering ignores any IPs listed in the above Message Delivery list.  This means, if an Exchange Edge server receives mail from an Ironport, if the Ironport IP is on that list, the Exchange Edge will then do a Connection Filteirng lookup on the last untrusted IP which would be the server that sent the mail to the Ironport (that is if the server that sent mail to Ironport is not also another internal device that is on the above list.

So, make sure you add all trusted IPs (Exchange and non-Exchange that are handling SMTP) internal to your organization to make sure Connection Filtering is working as it should be.

Share

Exchange 2010 SP1 and Blackberry Enterprise Server (BES)

Many will be upgrading to Exchange 2010 SP1 soon.  Many of you also have Blackberry Enterprise Server.  RIM has provided a pre-installation guide for Exchange 2010 here.  I wanted to touch on one of these pre-installation steps.  This is where we increase the maximum number of connections to the Address Book service.  The specific guide for this step is located here.  As you can see, you have to go into the following file “microsoft.exchange.addressbook.service.exe.config” and set MaxSessionsPerUser to 100000.

Note: Blackberry now has full support for Exchange 2010 SP1 as of 10/12/2010.  RIM retroactively modified their September 29th document to have full support when the same September 29th document previously only had Exchange 2010 SP1 listed with limited support. Please see the following document for support guidance which includes versioning information as well as a support KB article on supporting BES with Exchange 2010 SP1: http://na.blackberry.com/eng/support/software/server_exchange_ver_sept_29_10.pdf

In Exchange 2010 SP1, MaxSessionsPerUser does not exist anymore.  You can take a look at an Exchange 2010 SP1 “microsoft.exchange.addressbook.service.exe.config” file below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <runtime>
        <gcServer enabled="true" />
        <generatePublisherEvidence enabled="false"/>
    </runtime>
    <appSettings>
        <add key="NspiEndpointEnabled" value="true" />
        <add key="RfrEndpointEnabled" value="true" />
 
       <!-- Set port to an empty string to disable ncacn_ip_tcp. -->
        <!-- Set the port to 0 to allow the server to assign a port number dynamically. -->
        <add key="RpcTcpPort" value="0" />
 
        <!-- Set port to an empty string to disable ncacn_http for the specific interface -->
        <!-- Standard port assignments: Nspi=6004, Rfr=6002 -->
        <add key="NspiHttpPort" value="6004" />
        <add key="RfrHttpPort" value="6002" />
 
        <!-- Enables and disables the logging for the address book service. -->
        <add key="ProtocolLoggingEnabled" value="true" />
 
        <!-- Specifies the folder in which log files will be generated. -->
        <add key="LogFilePath" value="D:\Program Files\Microsoft\Exchange Server\V14\Logging\AddressBook Service\" />
 
        <!-- Specifies the max size that a single log file can grow to before a new one is generated. -->
        <add key="PerFileMaxSize" value="10MB" />
 
        <!-- Specifies the max size that the entire directory of logs can grow to before the oldest log is deleted. -->
        <add key="MaxDirectorySize" value="1GB" />
 
        <!-- Specifies length of time in hours log files will be retained before being deleted. -->
        <add key="MaxRetentionPeriod" value="720" />
 
        <!-- Specifies if we need to switch log file each hour. -->
        <add key="ApplyHourPrecision" value="true" />
    </appSettings>
</configuration>

So the big question here is, what do we do?  What do we need to make sure of prior to upgrading to Exchange 2010 SP1 to ensure the BESAdmin account does not have issues connecting to the Address Book Service?  Well, the reason why there is no more MaxSessionsPerUser is that the throttling mechanism was moved to the Throttling Policies and is shared with the RPC Client Access Service which uses the RCA* parameters in the Throttling Policies.

One of the prerequisites steps in the BES Documentation (even for RTM)  is to create a Throttling Policy for the BES Admin Account.  You can see that step here.  Because the Address Book throttling has been moved to the Throttling Policy using the RCA* parameters instead of the “microsoft.exchange.addressbook.service.exe.config” we will want to take a look at the throttling policy we created for the BESAdmin account and make sure the RCA* parameters are set to $null.

Run the following command on Exchange 2010 to check the throttling policy:

Get-ThrottlingPolicy BESPolicy

We will see results as such:

As we can see, the RCA* parameters are set to $null which means we will be safe upgrading to Exchange 2010 SP1.  If these parameters are not set to $null, set them to $null.  This can be done by running the following command:

Set-ThrottlingPolicy BESPolicy -RCAMaxConcurrency $null -RCAPercentTimeInAD $null -RCAPercentTimeInCAS $null -RCAPercentTimeInMailboxRPC $null

If you are doing a greenfield deployment of BES and need to create a new Throttling Policy with all of the options and then assign the BES Mailbox (assuming the mailbox is BESAdmin), run the following commands:

  1. New-ThrottlingPolicy BESPolicy
  2. Set-ThrottlingPolicy BESPolicy -RCAMaxConcurrency $null -RCAPercentTimeInAD $null -RCAPercentTimeInCAS $null -RCAPercentTimeInMailboxRPC $null -EWSMaxConcurrency $null -EWSPercentTimeInAD $null -EWSPercentTimeInCAS $null -EWSPercentTimeInMailboxRPC $null -EWSMaxSubscriptions $null -EWSFastSearchTimeoutInSeconds $null -EWSFindCountLimit $null
  3. Set-Mailbox “BESAdmin” -ThrottlingPolicy BESPolicy.
Share

Changes in Exchange 2010 SP1 Administrator Audit Logging

Exchange 2010 SP1 changes the way Administrator Audit Logging (AAL) works to some degree.  To see how Exchange 2010 RTM Administrator Audit Logging works, check out a great article by my fellow MVP Neil Hobson here.  This article is not going to explain what AAL is, just what the changes are.

In Exchange 2010 RTM, when you configured AAL, you had to specify what mailbox you were going to store data in.  This first required you to enable AAL and then to set the AAL Mailbox.  An example of this (which is also shown in Neil’s article) is done by running the following command:

Set-AdminAuditLogConfig –AdminAuditLogMailbox auditmailbox@shudnow.net

As an Administrator, you then had to give yourself full mailbox access to auditmailbox@shudnow.net.  For example, if your user account was elanadmin@shudnow.net, you would give yourself full mailbox access using the following cmdlet:

Add-MailboxPermission auditmailbox@shudnow.net -User elanadmin@shudnow.net -AccessRights FullAccess

You can now open the mailbox via OWA or Outlook to view the Administrator Audit Logs.

The Changes (Good Changes)

All the steps above I have just explained completely change in SP1.  In short, the changes include:

  • No more specified Mailbox exists.  In fact, the parameter AdminAuditLogMailbox has been removed.  It now uses a hidden mailbox (an arbitration mailbox to be precise) and you cannot change this.
  • All reporting is done in the Exchange Control Panel (ECP) which then creates a report based on the option you specify and sends it to the mailbox of choice.

Administrator Audit Logging Mailbox

As you can see, there is no AdminAuditLogMailbox parameter anymore.

As stated earlier, the data is now being stored in an Arbitration Mailbox. I welcome this change as it is less administrative work to have an additional mailbox when there’s already an arbitration mailbox with unlimited quota that can be storing this data instead.

Exchange Control Panel (ECP)

Logging into the ECP as an Administrator, we have the options to Manage Your Organization.  In fact, if you are a normal user with no elevated RBAC roles, you will not even see the option to Manage Your Organization.

In fact, let’s take a look at my regular user account and we’ll see what I’m talking about.

Now, let’s take a look at my administrator account (yes, I have a regular user account and a separate administrator account, and you should too – it’s called principle of least privilege and protected groups – aka adminsdholder issues).

As you can see, I have an option to Manage My Organization.  The other options in that drop down include:

  • Manage Myself
  • Manage Another User

But as we know, depending on the Exchange 2010 Administrative Model known as RBAC, some options may or may not appear in the ECP due to ECPs modular nature.  So if a user who has been added to the “Recipient Management” Group logs into ECP, they will see Manage My Organization but they may not see the Auditing.  So the question, what Role Groups out of the box have any kind of access to Auditing? Well, I did some PowerShell kung-fu and easily ran a one-liner (Powershell rocks!) and searched for which groups have access to this Auditing feature.  The PowerShell command I ran was:

Get-ManagementRole | Get-ManagementRoleAssignment | Where-Object {$_.Role -like “*audit*”} | FT Role,RoleAssigneeName -wrap -autosize

The result was the following:

We can see that some of our Role Groups (Organization Management and Exchange Organization Administrators) have several iterations of the Role.  This is due to the deleation type.  Regular means that the the Group has access to the commands that are specified in the role Audit Logs.  DelegatingOrgWide means the Role Group (Organization Management and Exchange Organization Administrators) have the power to assign the role to other Role Groups.

Moving on… now that we are in Manage My Organization Mode, we can see there is a Roles & Auditing Section now with an Auditing subsection.  From there, we can see that we can view some Auditing Reports.  These include the following reports:

  • Run a non-owner mailbox access report – allows you to search mailbox audit logs for mailboxes that have been accessed or changed by someone other than the owner.
  • Run a litigation hold report – allows you to search the administrator audit log for users who’ve had litigation hold enabled or disabled for their mailbox.
  • Run an administrator role group report – allows you to search the administrator audit log for changes made to role groups, which are used to assign administrative permissions to users.
  • Export mailbox audit logs – allows you to search for and export information about non-owner access to a mailbox during a specific time period.
  • Export the administrator audit log - allows you to search for and export information about configuration changes made in your organization.

The jist of it is that the first 3 that start with Run show the results within ECP itself.  The two Export options will allow you to specify a mailbox in the organization for which a report will be sent.  The report will look just as it did in RTM; an XML style result.

Let’s run through an Export  example. Let’s say a change was made in the organization and it’s not showing up in the logs.  We suspect that a rogue administrator had disabled Administrator Audit Logging.  We know this issue happened sometime between July 21st and July 23rd.  So we go into the Export the administrator audit log section.

We set the Start date to July 21st and the End date to July 23rd.  We then click Select users so we can choose the mailbox the report gets sent to.

I search for my mailbox and choose my mailbox as the mailbox to send the export to.

We then get the export report in e-mail.

The report can take several minutes and even longer depending on how much of a time period we are searching through. Once the report has been received, we can save the attached XML file and open it up in an XML Editor.  I chose to use XML Notepad.  We can see who the rogue admin was (it was me!… only doing my test of course).

We can also see what was done and what the old and new value were.

<Parameter Name=”AdminAuditLogEnabled” Value=”False” />

</CmdletParameters>

<ModifiedProperties>

<Property Name=”AdminAuditLogFlags” OldValue=”AdminAuditLogEnabled” NewValue=”None” />

<Property Name=”AdminAuditLogEnabled” OldValue=”True” NewValue=”False” />

</ModifiedProperties>

</Event>

Share

Exchange 2010 Database Activation Coordination (DAC)

Introduction and Database Activation Coordination (DAC) Support

Exchange 2010 introduced a vast amount of changes to the High Availability model with the addition of the Database Availability Group (DAG).  Some features of the DAG are having up to 16 members, automatic database *over to another site as long as you still have quorum, and much more.  Exchange also introduced Database Activation Coordination (DAC) mode as an optional addition to the new High Availability model to prevent split brain syndrome from occurring during a site switchover when utilizing a multi-site DAG configuration with at least 3 DAG members and more than one Active Directory Site.  DAC is off by default and in Exchange 2010 RTM it should not be enabled for:

  • 2 member DAGs
  • Non-Multisite DAGs
  • Multi-site DAGs that are in the same stretched Active Directory Site

In Exchange 2010 SP1,  the following changes are introduced and supported for DAC:

  • DAGs that contain 2 or more members
  • DAGs that are stretched across a single AD Site

Majority Node Set

Before we understand how DAC works, we really have to understand the Cluster Model that DAGs utilize.  Both Exchange 2007 and Exchange 2010 Clusters use Majority Node Set Clustering (MNS).  This means that 50% of your votes (server votes and/or 1 file share witness) need to be up and running.  The proper formula for this is (n / 2) + 1 where n is the number of DAG nodes within the DAG. With DAGs, if you have an odd number of DAG nodes in the same DAG (Cluster), you have an odd number of votes so you don’t have a witness.  If you have an even number of DAGs nodes, you will have a file share witness in case half of your nodes go down, you have a witness who will act as that extra +1 number.

So let’s go through an example.  Let’s say we have 3 servers. This means that we need (number of nodes which is 3 / 2) + 1  which equals 2 as you round down since you can’t have half a server/witness.  This means that at any given time, we need 2 of our nodes to be online which means we can sustain only 1 (either a server or a file share witness) failure in our DAG.  Now let’s say we have 4 servers.  This means that we need (number of nodes which is 4 / 2) + 1 which equals 3.  This means at any given time, we need 3 of our servers/witness to be online which means we can sustain 2 server failures or 1 server failure and 1 witness failure.

Note: Exchange 2010 DAGs do not use the term Majority Node Set anymore.  That term is deprecated and is now called Node Majority or Node Majority with File Share Witness.

Database Activation Coordination (DAC)

In short, DAC mode is enabled when you have at least 3 members to prevent split brain syndrome.  It’s as simple as that. Let’s take a look at an example and see how DAC can help. The longer explanation below talks about this specific model.

Prevention of Split Brain Syndrome

Short Explanation

When the Primary Site goes offline (or we lose too many servers – refer to Majority Node Set above), the Secondary Site will need to be manually activated should you make the choice that a secondary site activation will be required depending on the magnitude of the failure and how long you anticipate the primary site or servers there will be down.  But, when the Primary Site comes back online, the WAN link may be offline.  Because the Primary Site’s Exchange Servers don’t necessarily know about the Manual Site Switchover, they will come up thinking they have Quorum since the Primary Site has the majority of the servers and they are still connected to the old FSW.  Because of this, they will begin to mount databases since to them, they still have Quorum.

DAC mode will enable the usage of a new protocol, Database Activation Coordination Protocol (DACP). This means that DAG members start up with a special memory bit of 0.  They need to contact another DAG node with this special memory bit set to 1.  This memory bit will be set to 1 on one of the DAG members in the Secondary Site since that site is hosting active databases.  Because the WAN link is down, the Primary Site’s DAG members that just came online won’t be able to contact this DAG member with the special memory bit set to 1.  Because of this, they won’t be able to mount databases.  The WAN link will have to come back online which means the Primary Site’s DAG members will now be able to contact the DAG member that has the special memory bit set to 1 which will now allow the Primary Site’s DAG Members to be in a state where they are allowed to mount databases.

Longer Explanation

We can see in this example, there are 5 DAG nodes and no FSW as we have an odd number of DAG nodes.  Our entire Primary Datacenter Fails (or we lose too many servers – in our case, this would be (5 / 2) + 1 which means 3 of our nodes need to remain operational for the DAG to remain operational), the Secondary Site will need to be manually activated should you make the choice that a secondary site activation will be required depending on the magnitude of the failure and how long you anticipate the primary site or servers there will be down.

Part of the switchover process will have us shrink the DAG by removing the DAG nodes in the Primary Site from the cluster so all that remain of the existing 2 DAG nodes in the Secondary Site.  Instructions for shrinking the DAG and doing a manual site actiavtion is located here.  Should we decide to proceed with a a manual site switchover , we will provision the FSW in the secondary site during manual site activation to the secondary datacenter.  But what happens if the Primary Site’s Exchange Servers come back online?  They will think they have majority because the primary site has the majority of the servers and the FSW is located there.  Because of this, when they start up, they will begin mounting databases.

Now this is where DAC comes in.  Without DAC enabled, the Primary Site’s Exchange Servers would indeed come online, think they have majority, and begin mounting databases and you run into a split-brain syndrome scenario.  This is because when power is restored to the datacenter, the servers will usually come up before WAN connectivity is fully restored.  The servers cannot communicate with each other between the sites to see that the active databases are already mounted, and because of that, the Primary Exchange Servers will see they have majority since the majority of your servers and your FSW should be in the Primary Site, and mount the databases.

If the servers were allowed to mount databases, and you ran into a split-brain scenario, something called Database Divergence would occur. Database Divergence is where the databases in the primary site would become different from the secondary site causing  the need for a reseed from the authority database which would cause some database loss from the new database that went into the diverged database due to split-brain from occurring.

The way DAC works, is that all servers have a new protocol known as Database Activation Coordination Protocol (DACP).  One of the DAG Nodes will always have a special memory bit set to 1. What this means is, with DAC on, any time a server wants to mount a database, there are a few ways it will attempt to communicate with other DAG members:

  • If the starting DAG member can communicate with all other members, DACP bit switches to 1
  • If the starting DAG member can communicate with another member, and that other member’s DACP bit is set to 1, starting DAG member DACP bit switches to 1
  • If the starting DAG member can communicate with another member, and that other member’s DACP bits are set to 0, starting DAG member DACP bit remains at 0

Because of this, when the Primary DAG Servers come back online, they will need to either contact all other DAG members or contact a DAG member with DACP bit set to 1 in order to be in a state where it can begin mounting databases.  Because the WAN is down, these Primary Datacenter DAG Servers that are now just coming back online won’t be able to mount databases because none of these servers will have that special memory bit set to 1.  That memory bit will be set on one of the DAG Servers in the Secondary Site. Once WAN connectivity is restored, these Primary Datacenter DAG Servers will now be able to communicate with the DAG Server that happens to have that special memory bit set to 1 and now these DAG Servers will be allowed to mount databases.

Thankfully, in SP1, DAC will work with  2 node DAGs and multi-site DAGs that are using a stretched AD Site.

DAC and ForceQuorum

If you do not know what Forcequorum is,  have a quick look at my blog post here. Essentially, forcequorum allows you to forcefully start a cluster when this cluster has lost quorum.  You’re forcing it to bypass the Majority Node Set requirement to become operational.  In CCR, forcequorum was used in a geographically dispersed CCR cluster.  When the Primary Site went offline, you had to run forcequorum on the node in the Secondary Site and then set a new File Share Witness.  This is similar in Exchange 2010 DAGs when the Primary Site goes offline.

The article here is entitled Datacenter Switchovers and is the article to use when planning Site Resiliency with Exchange 2010.  You can see, in the procedure for terminating a failed site, there are two methods:

  • When the DAG is in DAC mode:
  • When the DAG isn’t in DAC mode

When looking at the procedures for when DAC is NOT enabled, there are more steps that have to be done which involve running clussvc commands.  When looking at the procedures for when DAC is enabled, there are no steps which involve running clussv commands.  This is because when you have DAC mode on, Exchange’s Site Resilient tasks allow it to perform these clussvc tasks in the background. As you can see, it is well worth it to ensure you have at least 3 DAG nodes in a DAG just to utilize DAC.  But again, in Exchange 2010 SP1, DAC can be utilized with DAGs that contain two nodes.

Share

Exchange Unified Messaging Provisioning Scripts

I recently wrote a Unified Messaging Provisioning Script and am providing it in two flavors; a simple version of it and the complex version of it.

Simple Script Features (CSV Download)

  1. $DefaultPIN is exactly that.  The CSV has a PIN column which is empty by default.  If this CSV field is left blank for a given user, it will use the $DefaultPIN.  Otherwise, it will use the PIN specified in the script.
  2. The Script will search for non-legacy Mailboxes (non-Exchange 2000/2003 Mailboxes if running Exchange 2007) and use the First and Last column (for the user’s first name and last name)  in Excel.  Because Firstname and Lastname is not unique in AD, the script will error on a user if they have multiple mailboxes.  It will tell you to enter the user’s Alias in that user’s Alias column in Excel.  The script will then get the mailbox that has that Alias.  This doesn’t just rely on Get-Mailbox -identity alias because that can still return multiple mailboxes.  It does a Get-Mailbox -identity alias but also does a Where-Object {$_.alias -eq $Mailbox.Alias} to ensure we use the correct mailbox.
  3. The script will enable the user’s UM Mailbox based on the Mailbox GUID on the mailbox that is retrieved to ensure enable the correct Mailbox based on the unique (GUID) identifier.
  4. Allows you to set the personal operator extension of a user based on the information in the CSV.  If you don’t need to set the Operator Extension, just go into the script and remove the Set-UMMailbox line as everything else is contained in the Enable-UMMailbox line.
  5. The script assumes you have one UM Mailbox Policy and uses that to assign users to.

Complex Script Features (CSV Download)

  1. Includes all the features of the Simple Script plus the following:
  2. Doesn’t send the default SMTP Message to user’s when they are UM Enabled.  The variable $NotifyEmail is where you want the welcome message sent which should obviously be a mailbox you perhaps create for the purpose of sending welcome messages to.
  3. Instead of sending the welcome message to the user’s mailbox when they are UM Enabled, the variable $smtpFrom is where you want a custom html formatted welcome message sent from.  This could be something such as ExchangeUMWelcome@domain.com.
  4. To tweak the custom HTML Formatted message, go down to the variable $EmailBody and include your own HTML.  By default, it will sent the user their PIN (if $DefaultPIN is used, that is sent to the user and if there’s a PIN for that user in the CSV, it uses that instead), their Extension, and their Subscriber Access Number as defined in the CSV.
  5. The script will allow you to choose from two separate UM Mailbox Policies.  By default, the script uses North America and London.  If you have different UM Mailbox Policies which you most likely will, you will need to go down to the Enable-UMMailbox command to tweak the name of the Policies that are used.  If you want to add more, you will need to modify the Write-Host lines near the beginning of the script which gives the user the option what to select and then go down to the Enable-UMMailbox and tweak the elseif pieces to take into consideration the additional UM Mailbox Policies to consider.

Note: The CSV file used for the Complex Script is available for download from here.  The one difference between this and the simple version of the CSV is this CSV contains a SubscriberAccess column which the HTML message captures and uses as a variable to send to the user’s primary SMTP address when enabl

Simple Script

?View Code POWERSHELL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
###############################
# UM Simple Automation v1
# By Elan Shudnow
###############################
 
########## MODIFIABLE OPTIONS ##########
# Set This PIN to the Default PIN.  If the CSV PIN Field is blank, it uses this.  If not blank, it uses the CSV PIN.
$DefaultPIN = 12345
 
# Set this to the location of the CSV file.
$mailboxes =  Import-CSV "UMsimple.csv"
 
########## DO NOT MODIFY ANYTHING BELOW THIS LINE ##########
 
# Call the Loop to Enable Users
Foreach ($mailbox in $mailboxes) {
 
	# By default, Excel will have empty Alias Column so it will search by First Last.
	if (!($mailbox.alias)) {
		$User = Get-Mailbox -Identity ($Mailbox.First + "" + " " + $Mailbox.Last) -ResultSize Unlimited -ErrorAction SilentlyContinue | Where-Object { $_.RecipientTypeDetails -eq "UserMailbox" }
	}
	else {
		$User = Get-Mailbox -Identity $Mailbox.Alias -ResultSize Unlimited -ErrorAction SilentlyContinue | Where-Object { $_.RecipientTypeDetails -eq "UserMailbox" -and $_.alias -eq $Mailbox.Alias }
	}
 
	# By default, Excel will have empty Alias Column so it will search by First Last.
	# This will notify you to modify the Alias Column so that you can search on a unique field if there are multiple
	# mailboxes with the same First Lastname that are on Exchange 2007.  The script ignores Exchange Legacy Mailboxes (Exchange 2000 and Exchange 2003).
	if ($User) {
		if ($User.Count -gt 1) {
			Write-Warning $User "There are multiple users with this First Name and Last Name.  Go into the spreadsheet and provide the alias for the correct mailbox user"
		}
		else {
			if ($User.UMEnabled -eq $false) {
				Enable-UMMailbox -Identity $User.GUID.toString() -ummailboxpolicy $((Get-UMMailboxPolicy).Identity) -pin $(if (!($mailbox.pin)) { $DefaultPIN } else { $Mailbox.PIN }) -pinexpired $true -Extensions $Mailbox.Extension -NotifyEmail $NotifyEmail
				Set-UMMailbox -Identity $User.GUID.toString() -OperatorNumber $Mailbox.Operator
			}
			else {
				Write-Host $User "is already enabled"
			}
		}
	}
	else {
		Write-Host "ERROR:" ($Mailbox.First + "" + " " + $Mailbox.Last) "'s Mailbox Does Not Exist"
	}
}

Complex Script

?View Code POWERSHELL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
###############################
# UM Complex Automation v1
# By Elan Shudnow
###############################
 
########## MODIFIABLE OPTIONS ##########
# Set This PIN to the Default PIN.  If the CSV PIN Field is blank, it uses this.  If not blank, it uses the CSV PIN.
$DefaultPIN = 12345
 
# Set this to the location of the CSV file.
$mailboxes =  Import-CSV "UMcomplex.csv"
 
# Set this to the Notify Email you want.
$NotifyEmail = "notifyname@domain.com"
 
# Set this to the e-mail address where users will receive Welcome Messages From
$smtpFrom = “smtpfrom@domain.com"
 
$smtpServer = "hubserver.domain.com"
 
########## DO NOT MODIFY ANYTHING BELOW THIS LINE ##########
 
# Allows the user running the script to choose which UM Mailbox Policy the group of users in the CSV
# should belong to.  This will assign the policy to all users in the given CSV file.
write-host
write-host Exchange Server 2010 - Unified Messaging Enabling
write-host Please, select which UM Mailbox Policy you want assigned
write-host
write-host '1) North America'
write-host '2) London'
write-host
$location = Read-Host "Select an option.. [1-2]? "
 
function Send-Email {
	Param ($To, $From, $Subject, $Body)
 
	$msg = New-Object Net.Mail.MailMessage
	$msg.From = $From
 
	$msg.To.Add($To)
 
	$msg.IsBodyHtml = $true
	$msg.Body = $Body
	$msg.Subject = $Subject
 
    $client = New-Object net.Mail.SmtpClient($smtpServer)
    $client.Send($msg)
}
 
# Call the Loop to Enable Users
Foreach ($mailbox in $mailboxes) {
 
	# By default, Excel will have empty Alias Column so it will search by First Last.
	if (!($mailbox.alias)) {
		$User = Get-Mailbox -Identity ($Mailbox.First + "" + " " + $Mailbox.Last) -ResultSize Unlimited -ErrorAction SilentlyContinue | Where-Object { $_.RecipientTypeDetails -eq "UserMailbox" }
	}
	else {
		$User = Get-Mailbox -Identity $Mailbox.Alias -ResultSize Unlimited -ErrorAction SilentlyContinue | Where-Object { $_.RecipientTypeDetails -eq "UserMailbox" -and $_.alias -eq $Mailbox.Alias }
	}
 
	# By default, Excel will have empty Alias Column so it will search by First Last.
	# This will notify you to modify the Alias Column so that you can search on a unique field if there are multiple
	# mailboxes with the same First Lastname that are on Exchange 2007.  The script ignores Exchange Legacy Mailboxes (Exchange 2000 and Exchange 2003).
	if ($User) {
		if ($User.Count -gt 1) {
			Write-Warning $User "There are multiple users with this First Name and Last Name.  Go into the spreadsheet and provide the alias for the correct mailbox user"
		}
		else {
			if ($User.UMEnabled -eq $false) {
				Enable-UMMailbox -Identity $User.GUID.toString() -ummailboxpolicy $(if ($location -eq 1) { "North America" } else { "London" }) -pin $(if (!($mailbox.pin)) { $DefaultPIN } else { $Mailbox.PIN }) -pinexpired $true -Extensions $Mailbox.Extension -NotifyEmail $NotifyEmail
				Set-UMMailbox -Identity $User.GUID.toString() -OperatorNumber $Mailbox.Operator
				$Extension = $Mailbox.Extension
				$Pin = $(if (!($mailbox.pin)) { $DefaultPIN } else { $Mailbox.PIN })
				$SubscriberNumber = $Mailbox.SubscriberNumber
$EmailBody = @"
Welcome to Exchange Unified Messaging!
 
Your Extension is $Extension
 
Your PIN is $Pin
 
Your Subcriber Access Number is $SubscriberNumber
 
"@
 
				$EmailSub = “Welcome to Exchange Unified Messaging!”
				$EmailTo = $User.PrimarySmtpAddress
				$EmailFrom = $smtpFrom
				Send-Email $EmailTo $EmailFrom $EmailSub $EmailBody
			}
			else {
				Write-Host $User "is already enabled"
			}
		}
	}
	else {
		Write-Host "ERROR:" ($Mailbox.First + "" + " " + $Mailbox.Last) "'s Mailbox Does Not Exist"
	}
}
Share

Exchange 2010 Databases and the RPCClientAccessServer Database Parameter

When you create an RPC Client Access Array AFTER you have created Exchange 2010 databases, you need to go back to those existing databases and stamp them with the RPC Client Access Array FQDN.  That way, clients will use that RPC Client Access Array.  Otherwise, they won’t.  On the other hand, if you create the RPC Client Access Array FQDN before you create your Exchange 2010 databases, nothing else is needed on your part.

There’s a bug with Outlook 2007 and Outlook 2010 that prevent the RPC Endpoint from updating.  This is similar to the bug in which Outlook 2007 will not update its Outlook Anywhere Endpoint which was fixed in Outlook 2010 Beta 2.  Because of this bug, it is very important that you get the RPCClientAccessServer database parameter configured correctly prior to moving users to Exchange 2010.  If you make this mistake and have the RPCClientAccessServer Database Parameter incorrectly and Outlook users are already hosted on Exchange 2010, once you modify the RPCClientAccessServer parameter for those clients, those clients can do an Outlook Profile Repair to get the updated change.  I will update this article in the future when this issue gets fixed.

So before you move users to Exchange 2010, please make sure that you either:

  1. Create the RPC Client Access Array before creating your databases OR
  2. Go back on the databases and stamp those databases by running the following command:
  3. Set-MailboxDatabase -Identity “DatabaseName” –RPCClientAccessServer array.domain.com

The reason why #1 works making #2 not necessary is the way Exchange assigns the RPC Client Access Array property to a database.  It does this in 3 different ways:

  1. If there is no RPC Client Access Array and you create the database on a server that hosts the MBX and CAS role, it will choose itself, always.
  2. If there is no RPC Client Access Array and you create the database on a server where the CAS and MBX are not collocated on the same server, it will randomly pick a CAS in the same site to set as the RPCClientAccessServer.
  3. If there is an RPC Client Access Array in that site, it will automatically set the FQDN of the CAS Array for the RPCClientAccessServer.

Autodiscover will see the database the user lives on and will assign the user’s Exchange Server (RPC Endpoint) to what the RPCClientAccessServer parameter is.  That is why it’s important to make sure this setting is right before a user is moved to Exchange 2010.

Share

Exchange 2010 SP1 Retention Policies

Exchange 2010 RTM introduced Retention Policies as the successor to the Message Records Management (MRM) technology introduced in Exchange 2007.  MRM was the successor to Mailbox Manager Policies in Exchange 2003.  Message Records Management is called MRM 1.0 and Retention Policies is being called MRM 2.0 for short. MRM 1.0 as well as MRM 2.0 are both available in Exchange 2010 but MRM 1.0 is being deprecated in Exchange 2010 SP1.

I won’t go into MRM 1.0 a whole lot but will show you the capabilities of Retention Policies in Exchange 2010, how it ties in with Outlook 2010, and how you can create Retention Policies via the Exchange Management Console in Exchange 2010 SP1.

Important: Please keep in mind that the screenshots below are not final as this article is based off of SP1 Beta software and may change by the time Exchange 2010 SP1 ships.

Retention Policy functionality

Default Policy Tag

A Default Policy Tag is the default Tag that is chosen for a Exchange specific folder such as Inbox, Calendar, Deleted Items, etc.  It affects all subfolders and subitems within that folder.  It is essentially the default policy/tag assigned to a specific folder. An example of a Default Policy Tag is when you enable a Personal Archive Mailbox for a user they are assigned a Default Policy Tag which says that all mailbox data will be moved to the archive after 2 years and it applies to all folders within an Exchange Mailbox.  Alternatively, you can also specify a specific part of the mailbox to be used for the Default Policy Tag instead (such as your Inbox, or Calendar, etc.)

Policy Tags

Policy Tags are the options available for a user to select on a Personal folder which are essentially any user created items which include a subfolder off of the Inbox, items created on your calendar, a user created task, and so on. This Policy Tag which is assigned to a Personal Folder is there to allow a user to override the Default Policy Tag.  It is essentially a way for a user to override the Default Policy (Default Policy Tag) set on a folder or a specific item or subfolder under the main folder that the Default Policy Tag is assigned to. So let’s say we enabled a Personal Archive Mailbox for a user and they have a Default Policy Tag for All Folders in a Mailbox for 2 years to be  pushed down to their Personal Archive Mailbox.  This Default Archive Policy also has a few Policy Tags that allow a user to select a folder or a specific item and choose the following options:

  • 1 year
  • 5 years
  • Never

By selecting 1 year, we are using the Retention Policy Tag that allows the user to select 1 year.  If we select User Folder Policy, we are essentially reverting back to the default setting which let’s the Default Policy Tag (2 years) to govern when that specific item gets moved to the archive.  So think of the Default Policy Tag as the default permission whereas a Policy Tag is a way for a user to override the Default Permission (the Default Policy Tag).

Retention Policy

A Retention Policy contains a Default Policy Tag and Policy Tags.  You assign this Retention Policy to a user.

A Walkthrough of Creating a Retention Policy in the Exchange Management Console

Microsoft is moving away from MRM 1.0.  In fact, in the Exchange 2010 SP1 Exchange Management Console, Managed Folders and Custom Managed Folders which were MRM 1.0 functionality has been removed.  The Exchange Management Shell still has MRM 1.0 functionality.  As you can see by the following image, there’s no Managed Folders or Custom Managed Folder tabs.  But, there is a Retention Policy Tags and a Retention Policies Tab.

The Scenario

Let’s say we have a MRM 1.0 policy that does the following: When an item is moved to Deleted Items, after 14 days it will be deleted with the ability to recover that deleted item.  In MRM 1.0 we couldn’t create any user configurable options.  But with Exchange 2010, we can use Policy Tags to allow our users to override the default we give them. We want to create a similar policy in Exchange 2010 SP1 (RTM did have Retention Policies but not the ability to create them in the Exchange Management Console).  We also want to take advantage of the Default Policy Tag to take care of the 14 day deletion but also provide additional Policy Tags to allow users to be able to choose a different time limit such as 7 days and 21 days.  Let’s go ahead and create a Default Policy Tag to Delete Items after 14 days.

So to recap the goals of our Retention Policy:

  • Default Policy Tag to delete all items in the Deleted Items folder after 14 days
  • Policy Tag to allow users to override the Default Policy Tag and be able to select 7 days for individual folders and/or items
  • Policy Tag to allow users to override the Default Policy Tag and be able to select 21 days for individual folders and/or items

So let’s create our first Retention Policy Tag which will become our Default Policy Tag because we are assigning it to a folder that Exchange creates, the Deleted Items folder.

We then want to allow the user the ability to select 7 days and 21 days. We will assign the Tag Type to Personal Folders which essentially makes it into a Policy Tag rather than a Default Policy Tag and will allow the users in Outlook 2010 to select 7 days or 21 days to override the Folder Policy (Default Policy Tag).

Let’s go ahead and create our 7 day Retention Tag.

Let’s go ahead and create our 21 day Retention Tag.

We can now see the Retention Tags and the Default Policy Tag.

So let’s go over to the Retention Policies Tab and create a new Retention Policy that includes all three of our Retention Policy Tags.

During the Policy creation we can specify mailboxes to associate the policy to; which I did.  After assigning the policy and running the Managed Folder Assistant (Start-ManagedFolderAssistant) to expedite the process of assigning the policy to the mailbox, I launched Outlook 2010 with this user’s account profile.

If we take a look at the Inbox Policy, it just says to use the Parent Policy.

But if we look at the Deleted Items Folder in which we created the Default Policy Tag for, we can see our Default Policy Tag at work.

Share

« Prev - Next »