Lync Server 2013 RTM

You will be pleased to know that the RTM version of Lync Server 2013 is now available for a free 180-Day evaluation!

 

Download the Latest Version

Exchange 2013 DAG CreateCluster() Failed Error

So far I have encountered the following problem in two completely separate Exchange 2013 Preview environments when creating a Database Availability Group [DAG].

Started by creating a simple DAG without any problems, only specifying its IP address and letting Exchange decide which server to use as the Witness Server. However, whenever I tried to add any of the mailbox servers to this DAG, I would get the following error:

 

Note the "CreateCluster() failed with 0x5. Error: Access is denied" part of the error message.

If we look at the dagtask log mentioned in the error above, we will see all the tasks Exchange performs when adding a server to the DAG and where it failed:

[2012-10-26T18:23:18] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseConfigureClusterAccount, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 94, szObjectName = DAG1 in organizational unit CN=Computers,DC=letsexchange,DC=com, dwStatus = 0x0 )

[2012-10-26T18:23:18] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseConfigureClusterAccount, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseFatal, dwPercentComplete = 94, szObjectName = DAG1 in organizational unit CN=Computers,DC=letsexchange,DC=com, dwStatus = 0x5 )

When dwStatus is 0x0, it means “success” but 0x5 means “access denied” just like the error we received in the Shell.

After some troubleshooting, I found out that the DAG’s Cluster Name Object [CNO] wasn’t created properly! There were two problems with the CNO:

1. The Exchange Trusted Subsystem universal security group didn’t have Full Access permissions to it;

2. The CNO was enabled in Active Directory:

After assigning full control to DAG1 AD object to the Exchange Trusted Subsystem and then disabling it, everything worked just fine:

 
For more information: Pre-stage the Cluster Network Object for a Database Availability Group

Hope this helps!

Wiped Mobile Devices Can Still Access Mailbox

When you wipe a mobile device that has a partnership with your Exchange environment, it might still be able to re-establish a connection and access the mailbox it had configured for 24 hours. This is the same as what happens with Outlook Web App and similar to when you disable an Active Directory account and the user can still use Outlook to access his/hers mailbox for up to 2 hours.

The solution to immediately prevent access to the mailbox after issuing a wipe is to:

1. Disable the mailbox;

2. Set a Send Prohibit Quota of 0KB;

3. Move the mailbox to another database.

If this is a mailbox in Office 365, then disable the protocols using the Set-CASMailbox cmdlet!

Exchange 2013 Beta Exams

Microsoft Exchange Server 2013 MCSE Beta Exams are now open for registration for Microsoft Learning Subject Matter Experts (SMEs):

• Beta exam – 71-341: Core Solutions of Microsoft Exchange Server 2013 Customer Preview
• Beta exam – 71-342: Advanced Solutions of Microsoft Exchange Server 2013 Customer Preview

The beta exam period will run from October 19th to November 8th 2012 and is based on Exchange 2013 Customer Preview. The live exams testing Exchange 2013 RTM will be released around January 2013.

For more details on the upcoming Exchange 2013 certifications: 70-341 and 70-342

Exchange 2013 RTM

Today the Exchange engineering team signed off the Release to Manufacturing (RTM) build of the new Exchange 2013. This means the coding and testing phase of the project is complete and they are now focused on releasing the new Exchange via multiple distribution channels. General availability is planned for the first quarter of 2013.

In addition to Exchange, the new Office, SharePoint, and Lync have also reached RTM.

Source: EHLO

iOS 6 Issues with Exchange

There have been some reports that iOS 6 is not working properly for many Exchange users... Apparently there are two issues:

Push E-mail

Push delivery of e-mail does not work, meaning users have to manually check for e-mails. It seems that this issue is not carrier or device specific and rebooting or reconfiguring the Exchange accounts only “fixes” the issue temporarily.

Meetings

This second issue happens when users decline a meeting invitation from an iOS 6 device. Instead of simply sending a notification to the meeting organizer, iOS 6 sends meeting cancellation notices to the entire group of attendees, cancelling the invitation for everyone!

In the environment where I work, we don’t seem to be experiencing any of these issues. Initially I asked colleagues if they were having any problems with push e-mail and they were all working fine (I believe our ServiceDesk has not received any calls regarding this yet – we have 651 devices on iOS 6 so far).

As to the second issue, I tested it three times with different users and with the new iPad, iPhone 4S and iPhone 5 and couldn’t replicate the issue...

However, this seems to be affecting many, many Exchange 2007/2010 organizations out there, so please be aware of this and test it!

UPDATE: The Exchange Team has just published a post on this: iOS6 devices erroneously take ownership of meetings!

UPDATE 2: looks like Apple has released an update for iOS 6 (available via iTunes and wirelessly) which supposedly fixes the issues of this OS with Microsoft Exchange meetings! More information here.

List Litigation Hold Users and Size

A feature introduced in Exchange 2010 RTM and that is being used more and more it Litigation Hold. It is used during a lawsuit, investigation or similar events to preserve mailbox items from inadvertent or purposeful modification or deletion by the user (or someone with access to the mailbox) and from automated deletion by retention policies. Until the hold is removed, deleted items are not purged from the mailbox database and if a mailbox item is modified, a copy of the original item is also retained. These are returned in Discovery searches performed when the mailbox is on Litigation Hold. Any retention policies applicable to the mailbox don't need to be suspended. Because messages continue to be deleted as expected (except from the Recoverable Items\Purges folder!), users may not notice they're on Litigation Hold.

 

To check if there are any users in your organization currently enabled for Litigation Hold, simply run the following cmdlet:

Get-Mailbox -ResultSize Unlimited -Filter {LitigationHoldEnabled -eq $True}

If you want to check the Recoverable Items folder size for all mailboxes on Litigation Hold, i.e. how many data is being held by Litigation Hold, use the following cmdlet:

Get-Mailbox -ResultSize Unlimited -Filter {LitigationHoldEnabled -eq $True} | Get-MailboxFolderStatistics –FolderScope RecoverableItems | FT Identity, FolderAndSubfolderSize

 

Or if you simply want to check a single mailbox:

Get-MailboxFolderStatistics <user> -FolderScope RecoverableItems | Select Identity, FolderAndSubfolderSize

Hope this helps!

How to Determine Continuous Replication Mode (Block Mode or File Mode)?

In Exchange 2007 and 2010, Continuous Replication operates by shipping copies of the logs created by the active database copy to the passive database copies. With Exchange 2010 SP1, this is known as Continuous Replication - File Mode as the log file is only copied once it is full (1MB). But SP1 introduces a new form of continuous replication known as Continuous Replication - Block Mode. In block mode, when an update is written to the active database log file it is immediately copied to the passive mailbox copies, thus reducing the latency between the time a change is made on the active copy and the time that same change is replicated to a passive copy. This way, if a failure occurs on the active copy, the passive copies will have been updated with most or all of the latest updates.

However, Block Mode is only active when continuous replication is up-to-date in file mode. The Log Copier component monitors the copy and replay queue lengths of databases as transaction logs are generated and takes care of transitioning into and out of block mode automatically.

To determine if continuous replication is operating in block mode or file mode, use the following cmdlet:

Get-Counter -ComputerName <<DAG_Member_Name>> -Counter “\MSExchange Replication(*)\Continuous replication - block mode Active”

The output will be something similar to:

Timestamp                 CounterSamples

---------                 --------------

04/09/2012 11:39:46       \\MBX1\\msexchange replication(mdb31)\continuous replication - block mode active : 1

                          \\ MBX1\\msexchange replication(mdb32)\continuous replication - block mode active : 1

                          \\ MBX1\\msexchange replication(mdb33)\continuous replication - block mode active : 0

Here, the “1” means that block mode is active while a “0” means it is not. However, note that your active databases will always show “0”, we are just interested in the passive copies!

Mailboxes Quarantined due to Troubleshoot-DatabaseSpace.ps1 Script

Exchange 2010 SP1 added a new script called Troubleshoot-DatabaseSpace.ps1 that is used to detect excessive growth of database and log drive volumes. This script can be run manually by administrators but if you have Microsoft System Center Operations Manager (SCOM) 2007 it is run automatically every 15 minutes.

This script performs the following actions:

1. Track log generation rate for the highest log generators (mailboxes) per database. This helps determine which users are logging too heavily and potentially causing space issues;

2. Track available disk space for both database and log files. If either of these is within a configurable threshold of being full (25% by default), further action must is taken;

3. Track log generation rate. If it appears that the disk is going to run out of space within the value specified by the HourThreshold parameter (12 hours by default and based on the log generation rate), further action is taken;

4. If all of the above conditions are fulfilled, the script determines the list of top 25 users who accessed the database during the last 1 hour period. The script then quarantines the top high-usage mailboxes for 6 hours, during which they will not have access to e-mail;

5. If the troubleshooter is unsuccessful at dropping the log generation rate to below the threshold level, it will write out events that translate into health model alerts. At this point, the script removes the database from provisioning by running the Set-MailboxDatabase cmdlet with the ExcludeFromProvisioning parameter set to $True against the specified database;

When mailboxes are quarantined, you will see entries in the Registry of the mailbox server hosting that database/mailbox in:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\"server_name"\Private-"DB.Guid"\"Mailbox_Guid"

To check the events logged by this script go to the mailbox server you want to check and then Event Viewer -> Application and Services Logs -> Microsoft-Exchange-Troubleshooters/Operational. Note that if you run the script manually through the Shell it will not produce any output - you have to check the Event Viewer.

If you run the script manually without any parameters or if you have SCOM running this script automatically, then it will use default values specified in the StoreTSConstants.ps1 script located in the same folder. This is where you can customize the 25% threshold, for example, if it is not ideal for your environment:

   # The percentage of disk space for the EDB file at which we should start quarantining users.

   $PercentEdbFreeSpaceDefaultThreshold = 25

   # The percentage of disk space for the logs at which we should start quarantining users.

   $PercentLogFreeSpaceDefaultThreshold = 25

   # The percentage of disk space for the EDB file at which we are at alert levels.

   $PercentEdbFreeSpaceAlertThreshold = 16

   # The percentage of disk space for the EDB file at which we are at critical levels.

   $PercentEdbFreeSpaceCriticalThreshold = 8

   #The number of hours we can wait before running out of space.

   $HourDefaultThreshold = 12

In order for mailboxes to be quarantined, the –Quarantine parameter must be passed to the script, which the SCOM monitor uses by default. Because the Exchange Management Pack is sealed, you can’t change this...

So, if 25% is too high for your environment, you can change the value by updating the StoreTSConstants.ps1 script across all your mailbox servers or, ultimately, simply disable the SCOM monitors that run this script:

• KHI: Failed to execute Troubleshoot-DatabaseSpace.ps1

• KHI:The database copy is low on database volume space and continues to grow. The volume has reached critical levels 8% free.

• KHI:The database copy is low on database volume space and continues to grow. The volume has reached error levels under 16% free.

• KHI:The database copy is low on database volume space and continues to grow. The volume is under 25% free.

Resubmit Messages in Queues

There might come a time where you experience a problem with you Hub/Edge Transport servers, Mailbox servers or e-mail gateway and messages are stuck in Queues. Once you resolve the issue, you can either wait a few minutes for Exchange to resubmit the e-mails or you can manually resubmit them to the Submission queue for the categorizer to reprocess as long as they have the following status:

·         Mailbox delivery queues or remote delivery queues that have the status of Retry. The messages in the queues must not be in the Suspended state;

·         Messages in the Unreachable queue that aren't in the Suspended state;

·         Messages in the poison message queue.

 

 

To manually resubmit messages, you can use the following methods (examples below):

·         Use the Retry-Queue cmdlet with the -Resubmit parameter;

·         Export the messages to .eml message files and resubmit them by placing them in the Replay directory;

·         Use Queue Viewer or the Resume-Message cmdlet to resubmit the messages in the poison message queue. You can’t use the Retry-Queue with the -Resubmit parameter cmdlet to resubmit messages in the Poison Queues.

 

 

By using the –Resubmit parameter, messages are forced to be resubmitted through the Categorizer for a new delivery attempt. If you do not use the –Resubmit parameter, the delivery queue will try to connect to the next hop immediately without resubmitting the messages through the Categorizer.

 

 

Let’s look at a few examples:

1. To export a copy of a message (so you can put it into the Replay directory) that has an InternalMessageID of 1234 that's located in the remote delivery queue for the domain MSExchange.org on the server HUB01 to the path C:\MSExchange Export\export.eml:

Export-Message HUB01\MSExchange.org\1234 -Path “C:\MSExchange Export\export.eml”

2. To resubmit all the messages in the 62306 delivery queue of the HUB01 server, use the following cmdlet (you can’t use the EMC):

Retry-Queue “HUB01\62306” -Resubmit $True

3. To resubmit all the messages in all delivery queues of server HUB01 that have a status of Retry (again, you can’t use the EMC):

Retry-Queue –Server “HUB01” -Filter {Status -eq "Retry"} -Resubmit $True

4. To resubmit all messages located in the Unreachable queue of server HUB01, use the following cmdlet (again, you can’t use the EMC):

Retry-Queue “HUB01\Unreachable” -Resubmit $True

5. Let’s force a connection attempt for all queues that are holding messages for the domain msexhange.org, have a status of Retry and are located on the server HUB01:

Retry-Queue –Server “HUB01” -Filter {NextHopDomain -eq “msexchange.org” -and Status -eq “Retry”}

 

6. To resubmit messages in the Poison Queues, you have to resume the messages. As I mentioned previously, the Poison Queue cannot be resubmitted by using the Retry-Queue cmdlet with the -Resubmit parameter.

Remember that the Poison Queue contains messages that are determined to be harmful to the Exchange system after a server failure. They may also be victims of a poorly written agent that crashed the Exchange server while it was processing them. If you're unsure of the safety of the messages in the poison message queue, you should export them to files so you can examine them.

 

Using the Exchange Management Console to resume messages in the Poison Queue:

1.       In the EMC click Toolbox;

2.       Open the Queue Viewer tool;

3.       In Queue Viewer, click the Queues tab;

4.       Click the Poison Queue and select View Messages;

5.       Select one or more messages from the list, right-click them and select Resume.

 

To use the Shell you must first determine the identity of the message to be resumed. This example will show the identity of all messages in the poison queue:

Get-Message -Queue “Poison” | Select Identity

 

Now you can use the identity to resume the message. For example, let’s resume the message with an identity value of 123:

Resume-Message 123

 

Exchange 2010 EventID 9320 and 9359

During the generation of your Offline Address Book [OAB] you might see the following warning logged in the Exchange server responsible for generating the OAB:

Log Name:      Application

Source:        MSExchangeSA

Date:          05/07/2012 05:02:35

Event ID:      9320

Task Category: (13)

Level:         Warning

Keywords:      Classic

User:          N/A

Computer:      SERVER.domain.com

Description:

OABGen could not generate full details for some entries in the offline address list for address list '\Global Address List'.  To see which entries are affected, set event logging for the offline address list generator to at least medium.

And a similar warning to the one below for many of your users:

Log Name:      Application

Source:        MSExchangeSA

Date:          05/07/2012 05:02:08

Event ID:      9359

Task Category: (13)

Level:         Information

Keywords:      Classic

User:          N/A

Computer:      SERVER.domain.com

Description:

OALGen truncated or dropped properties for entry 'USERNAME' in address list '\Global Address List' because they exceeded the configured size limits for the version 4 offline address list.  The affected MAPI ids are:  8008. 

- \Default Offline Address List 

The possible affected MAPI IDs are:

• 0x8CD8000D = PR_EMS_AB_AUTH_ORIG

• 0x8008101F = PR_EMS_AB_IS_MEMBER_OF_DL_W

The example above with the 8008 ID is generated for each user in the OAB that is a member of a Distribution List [DL] and for each DL that has members.

This happened because the Active Directory attributes member and memberOf are not part of the truncated property list for regular groups. So when the OAB is being generated, this property is read but because Exchange can’t see it in the list, a 9359 event gets logged.

It looks like this is by design so, at the moment, there is no workaround or a way to suppress these warnings. The good news are that these warnings are expected, can be ignored and Microsoft has plans to address this!

Users do not receive quota warning messages

We all know that, for better or for worse, the way Exchange calculates and sends Quota Messages changed with Exchange 2010 SP1. We also know that this has caused nothing but confusion for many Administrators out there...

In this post I will try to give an overview of the new behaviour for normal mailboxes and, more important, explain when users will actually receive these messages.

Pre Exchange 2010 SP1

In Exchange environments previous to Exchange 2010 SP1, Exchange sends a quota message to mailbox owners when a:

1. Mailbox exceeds its IssueWarningQuota limit (the lowest storage quota);

2. Mailbox exceeds its ProhibitSendQuota limit (the middle storage quota);

3. Mailbox exceeds its ProhibitSendReceiveQuota limit (the highest storage quota).

Remember that:

• quota messages are sent to mailbox owners, so if a mailbox is owned by a security group (shared mailbox), quota messages are sent to the security group;

• quota messages are sent with high importance and are not subject to storage quotas, which means they are always delivered even if the recipient's mailbox is full;

• quotas can be configured at a mailbox or database level.

These quota messages are sent during the QuotaNotificationSchedule specified for each mailbox database, which would normally be something like every day from 4AM to 6AM:

Get-MailboxDatabase | Set-MailboxDatabase -QuotaNotificationSchedule “Mon.04:00-Mon.06:00, Tue.04:00-Tue.06:00, Wed.04:00-Wed.06:00, Thu.04:00-Thu.06:00, Fri.04:00-Fri.06:00, Sat.04:00-Sat.06:00, Sun.04:00-Sun.06:00”

During this period, Exchange goes through every mailbox in the database(s) and if any has exceeded the quota threshold, it sends the owner an e-mail. No matter if the schedule was 1h, 2h or 10h, as long as Exchange has enough time to go through every mailbox, everyone over quota receives one warning message.

Exchange 2010 SP1 Onwards

Now comes SP1 and all hell breaks loose... We still have:

• the same 3 levels of quotas;

• quotas configurable at the user or database level;

• quota messages sent during the QuotaNotificationSchedule.

BUT.... The way these messages are generated has changed... Now, every mailbox has a flag that controls whether it is checked to see if it has exceed a quota threshold. This flag is only set if the mailbox size is more than 50% of the ProhibitSendQuota limit! Unfortunately, this flag is a system property (part of the code) and therefore not visible using MFCMapi...

Let’s take an example and imagine a mailbox currently 450MB in size. This mailbox (or its database) has IssueWarningQuota set to 400MB and ProhibitSendQuota set to 1GB. We can see the mailbox is over its warning limit but because 450MB is not over 50% of the ProhibitSendQuota (500MB), it will not be checked and will not receive a quota warning message!

On top of this, once a mailbox has been checked during the QuotaNotificationSchedule, the flag is cleared and the mailbox will not be checked again until the flag is reset. Now, here’s the problem I found: according to Microsoft documentation, this flag is reset when “either a message is saved in the mailbox or a message is submitted”. When this happens, if the mailbox size is more than 50% of the ProhibitSendQuota, the flag is reset and the mailbox will be checked during the next QuotaNotificationSchedule.

But what exactly is a saved message?! I assumed that if a user drafted a message and saved it without sending it, the flag would be reset. However, from my tests this is not the case... So far, only sending e-mails from a mailbox seems to reset this flag. This means that if you have a mailbox that only receives e-mails, it will never receive the warning message. Again, this is what I am seeing in the environment I work at and from my tests!

You might be asking why I previously emphasised the “1” in “everyone over quota receives one warning message”. By default, with SP1 the QuotaNotificationSchedule is set to run for 15 minutes every day at 1AM. If you increase this to 2h, for example, your users might receive more than one message at a time! I had cases where I had this set to run over 3h for testing purposes, and some users received 3 quota messages...

Troubleshooting

If you would like to see if/which mailboxes are over quota or received a quota message, you have a few methods:

Increase the diagnostic logging on the mailbox server you want to check:

1. Open the Exchange Management Console;

2. Choose Server Configuration;

3. Select the the server name under Server Configuration for which you want to increase logging ;

4. Choose Manage Diagnostic Logging Properties... under the Actions pane;

5. Expand MSExchangeIS;

6. Expand 900 Private;

7. Choose Storage Limits;

8. Select the Expert radio button and click Configure;

9. You don’t need to restart the MSExchangeIS service or dismount and remount the database stores;

10. The next time the QuotaNotificationSchedule runs, look for the EventID 1077 in the Application log.

Use PowerShell to check mailbox statistics:

Get-MailboxStatistics -Database MDB01 | ? {$_.StorageLimitStatus -eq "IssueWarning" -OR $_.StorageLimitStatus -eq "ProhibitSend" -OR $_.StorageLimitStatus -eq "ProhibitSendReceive"} | Select DisplayName, Alias, StorageLimitStatus

Use PowerShell to see which users received a quota message:

Get-TransportServer | Get-MessageTrackingLog -ResultSize Unlimited -Start "08/08/2012" -MessageSubject "your mailbox is" –EventID DELIVER | Select TimeStamp, Recipients, MessageSubject

Exchange 2013

I have been doing some tests with Exchange 2013 to check if the behaviour is the same, but for some reason Exchange doesn’t seem to check my mailbox for quotas...

From the screenshot below, you will see that:

1. Database DB1 has ProhibitSendQuota set to 400MB and IssueWarningQuota to 200MB;

2. My mailbox is using the database’s quota defaults;

3. My mailbox is over the IssueWarningQuota limit with a size of 246MB

4. Exchange has not set the StorageLimitsStatus for my mailbox which should say IssueWarning (if it’s the same as 2007 and 2010).

It was only when I set quota limits at the mailbox level that I started to get warning messages, so I am still trying to understand exactly what is going on with Exchange 2013...

Conclusion

To reiterate, from Exchange 2010 SP1 onwards:

• Every mailbox has a flag to control if the mailbox’s quota is checked;

• This flag is only set if the mailbox size is more than 50% of the ProhibitSendQuota limit;
• If ProhibitSendQuota limit is not used, users will never receive a quota message; 

• If the flag is set, Exchange will send a quota message during the QuotaNotificationSchedule interval and then clear the flag;

• The flag is reset only when a message is sent from the mailbox;

Hope this helps clarifying the new behaviour regarding quota messages!

Exchange 2010 SP2 Update Rollup 4

"On August 13th 2012, the Exchange CXP team released Update Rollup 4 for Exchange Server 2010 SP2 to the Download Center.

This update contains a number of customer reported and internally found issues. See KB 2706690 - Description of Update Rollup 4 for Exchange Server 2010 Service Pack 2 for more details."

Exchange 2007 SP3 Update Rollup 8

"On August 13th 2012, the Exchange CXP team released Update Rollup 8 for Exchange Server 2007 SP3 to the Download Center.

This update contains a number of customer reported and internally found issues. See KB 2734323 - Description of Update Rollup 8 for Exchange Server 2007 Service Pack 3 for more details."

DirSync Filtering

Introduction

If you subscribe to Microsoft Office 365 (with the exception of the Small Business Plan) and your company already has users in a local Active Directory [AD] environment, you can use the Microsoft Online Services Directory Synchronization [DirSync] tool to synchronize those users to your Office 365 directory.

By using DirSync, you can keep your local AD in constant synchronization with Office 365 so that any changes made to users such as contact updates for example, are propagated to Office 365.

This allows you not only to create synchronized versions of each user account and group, but also allows Global Address List [GAL] synchronization from your local Exchange environment to Exchange Online.

Synchronization

Until now, one of the problems of DirSync was that it would sync your entire AD to Office 365. This means that if you had 10,000 AD users and only wanted 500 in Office 365, you would have all 10,000 users listed in Office 365... There were a couple of methods of excluding certain objects, but none supported by Microsoft.

DirSync Filtering has been possible for early Office 365 for Education customers but now it is available to all customers, allowing you to easily exclude Organizational Units [OUs], for example, from being synchronized. Let’s have a look.

DirSync is simply a pre-configured Microsoft Identity Integration Server [MIIS] installation specific for Office 365 integration. What some administrators don’t know is that MIIS can be customized by using the MIIS Client located at:

• 32-bit: %SystemDrive%\Program Files\Microsoft Online Directory Sync\SYNCBUS\UIShell

• 64-bit: %SystemDrive%\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell

WARNING: Before we proceed, please be very careful when using MIIS Client as it can cause harm to your office 365 environment if not used properly!

Filtering

At the time of writing of this post, there are 3 filtering options that can be applied to DirSync:

1. Organizational Units based, which allows you to select which OUs are to be synced to the cloud;

2. Domain based, allowing you to select which domains are synchronized to the cloud;

3. User attribute based, enabling you to control which objects shouldn’t be synchronized to the cloud based on their AD attributes.

NOTE: If you have already run DirSync and synced all your AD into Office 365, the objects that you now filter will no longer be synchronized and will be deleted from the cloud! If you excluded, and subsequently deleted objects because of a filtering error, you can easily re-create them in the cloud by removing the filter and then syncing the directories again.

Organizational Units Based Filtering

1. Log on to the computer that is running DirSync by using an account that is a member of the MIISAdmins local group;

2. Open MIIS by running miisclient.exe;

3. In Synchronization Service Manager, click Management Agents and then double-click SourceAD;

4. Click Configure Directory Partitions and then click Containers;

5. When prompted, enter domain credentials for your on-premises domain and then click OK;

6. In the Select Containers dialog box, clear the OUs that you don’t want to sync;

7. If you click in Advanced... you will be able to further control which OUs to include and exclude;

8. Click OK three times;

9. On the Management Agent tab, right-click SourceAD, click Run, click Full Import Full Sync and then click OK to perform a full sync;

10. Once finished, you can check the results at the bottom left corner of the window.

Domain Based Filtering

1. Log on to the computer that is running DirSync by using an account that is a member of the MIISAdmins local group;

2. Open MIIS by running miisclient.exe;

3. In Synchronization Service Manager, click Management Agents and then double-click SourceAD;

4. Click Configure Directory Partitions and then select the domains that you want to synchronize. Because in my environment there is only one domain, I only get one domain listed. To exclude a domain simply clear its check box;

5. Click OK;

6. On the Management Agent tab, right-click SourceAD, click Run, click Full Import Full Sync and then click OK to perform a full sync;

7. Once finished, you can check the results at the bottom left corner of the window.

User Attribute Based Filtering

As the name suggests, this third option can only be applied to user objects. It is possible to filter contacts and groups, but these use other and more complex filtering rules.

To exclude users from filtering, we can utilize around 114 AD attributes. For example, you can set extensionAttribute10 to “noOffice365” for all the users you don’t want to sync and then create a filter rule to exclude these from synchronization. After you configure in AD the attribute you want to look, here’s how you configure MIIS:

1. Log on to the computer that is running DirSync by using an account that is a member of the MIISAdmins local group;

2. Open MIIS by running miisclient.exe;

3. In Synchronization Service Manager, click Management Agents and then double-click SourceAD;

4. Click Configure Connector Filter;

5. Select user in the Data Source Object Type column. In here you can see some examples of accounts being excluded already such as Exchange System mailboxes or the MSOL_AD_Sync account used by DirSync;

6. Click New;

7. In Filter for user, on the Data Source attribute, select extensionAttribute10. For Operator select Equals and then type noOffice365 in the Value field. Click Add Condition and then click OK;

8. Click OK again;

9. On the Management Agent tab, right-click SourceAD, click Run, click Full Import Full Sync and then click OK to perform a full sync;

10. Once finished, you can check the results at the bottom left corner of the window.

Hope this helps!