Exchange 2013 Message Headers

As you might have seen in the Exchange 2013 Mail Flow article, the Transport Pipeline is now made of three main services:

1. Front End Transport service, which runs on all Client Access servers (CAS) and acts as a stateless proxy for all inbound and outbound external SMTP traffic;
2. Transport service which runs on all Mailbox servers and is almost identical to the Hub Transport server role in previous versions of Exchange;
3. Mailbox Transport service which also runs on all Mailbox servers and is made of two separate services, the Mailbox Transport Delivery service and the Mailbox Transport Submission service.

Because of this change in architecture, the message headers in Exchange 2013 have been updated to include information regarding which service(s) dealt with the message, making it easier to troubleshoot any possible issues.

 

For example, if we look at an e-mail received from the Internet, into a CAS server and then delivered to a user’s mailbox, we can see that both the Front End Transport service and the Mailbox Transport service dealt with the message:

 

 

On the other hand, if we look at an internal e-mail, we do not see the Front End Transport service as the e-mail does not go through this service if it is from an internal user to another internal user:

Exchange 2013 E-mail Traffic From inboundproxy@inboundproxy.com and HealthMailbox

In Exchange 2013, native, built-in monitoring and recovery actions are included in a feature called Managed Availability, which is made up of two processes: the Microsoft Exchange Health Manager Service (MSExchangeHMHost.exe) and the Microsoft Exchange Health Manager Worker process (MSExchangeHMWorker.exe), and the following components:

• The Probe Engine takes measurements on the server;
• The Monitoring Probe Engine stores the business logic about what constitutes a healthy state. It functions like a pattern recognition engine, looking for patterns and measurements that differ from a healthy state, and then evaluating whether a component or feature is unhealthy;
• The Responder Engine, when alerted about an unhealthy component, first tries to recover that component. The first attempt may be to restart the application pool, the second attempt may be to restart the corresponding service and the third attempt may be to restart the server. The final attempt may be to put the server offline, so that it no longer accepts traffic.

Exchange 2013 automatically creates several HealthMailbox"guid" objects in Active Directory which are used by Managed Availability to send e-mails through Exchange to verify mail flow every few minutes. These e-mails are used to do health checks for resources from FrontEnd Transport service to Transport Service and health checks on mailbox database resources. The same Microsoft Exchange Health Manager Service is responsible for both these health checks.

Two health mailboxes are created for each mailbox database: one for mailboxes and one for Public Folders (if these are deployed). You can view these hidden mailboxes using Active Directory Users and Computers. You need to enable Advanced Features and then navigate to Microsoft Exchange System Objects and then Monitoring Mailboxes:

Or you can use the Exchange Management Shell and run the following cmdlet:

Get-Mailbox -Monitoring

 

 

This is why in an Exchange 2013 environment you will see lots of traffic from the e-mail addresses inboundproxy@inboundproxy.com, MailDeliveryProbe@MailDeliveryProbe.com and HealthMailbox(...)@domain.com with the subjects of “MBTSubmission/StoreDriverSubmission/(...)-MapiSubmitLAMProve”, “Inbound proxy probe” or “Client submission probe”.

This is by design!

Windows Azure Active Directory Synchronization Tool Version Release History

If you are finding it hard to keep up with all the improvements made to DirSync as well as all its versions, this Wiki keeps track of the versions that have been released and lists the main changes introduced.

Outlook Web App Views

As with previous versions of Exchange, Outlook Web App [OWA] in Exchange 2013 and the new Office 365 comes in two flavors:

• OWA Premium: available in computers, tablets and phone optimized UI. Desktops must be using Internet Explorer 8+ and newer versions of Safari, Chrome and Firefox. As for tablets and phones, the supported versions are (for now) Windows 8 tablets, iOS6 on iPad2+ and iPhone 4+. Although not supported, the new OWA UI works just fine on recent Android mobile phones and tablets;
• OWA Light: this is what users get on any browser not supported with OWA Premium. It uses a very simple HTML4 based UI which works in pretty much any browser in existence and remains the same as with the previous release of Exchange/OWA. A special note to say that IE7 now gets OWA Light as well...

OWA Premium has three different views:

• The traditional Desktop view with a 3-columns mouse-based UI;
• The Table view with a 2-columns touch UI also known as twide;
• The Phone view with a 1-column touch UI also known as tnarrow.

Even if you do not have a tablet or a phone to test how these two different views look like, you can easily use your desktop browser to emulate them. To do so, use the following URLs:

• https://<FQDN>/owa/?layout=twide
• https://<FQDN>/owa/?layout=tnarrow

Exchange Online Mailbox Size Now 50GB!

The size of user mailboxes in all Exchange Online and Office 365 service plans just doubled!

 

Since last week (end of August), the 25GB of mailbox storage increased to 50GB. There is no price increase associated with this change as the doubling of mailbox storage is simply part of Microsoft's promise to continuously deliver value to Office 365 customers. 

 

Customers don't need to do anything to take advantage of this new mailbox size as mailbox sizes will automatically be increased. This increase has already started and continues through November.

 

This increase to a 50GB mailbox per user benefits Exchange Online and Office 365 service plans, including: Exchange Online Plan 1, Office 365 Small Business, Midsize Business, Enterprise E1, Government G1, and Education A1.

Customers with a premium service plan (Exchange Online Plan 2, Office 365 Enterprise E3 and E4, Government G3 and G4, Education A3 and A4), already enjoy unlimited e-mail storage through personal archive, but now the default primary mailbox size is increasing to 50GB. Kiosk user mailboxes are doubling in size too, from 1 to 2GB.

 

In addition to doubling the storage of users' primary mailboxes, Microsoft has also increased the size of other mailboxes: shared mailboxes and resource mailboxes are both increasing to 10GB (more than double), but the size of Site mailboxes remains unchanged.

 

For complete details about mailbox types and sizes, read the Office 365 Service Descriptions.

 

Source: Office 365 Technology

MS Exchange CON 2013 Virtual Conference

Get your top Microsoft Exchange questions answered!

- Hear from a top analyst from Osterman Research with the latest survey research on Exchange top trends and challenges;
- Watch how vendors are solving some of the biggest Exchange Management problems;
- Get answers to your top Exchange and Exchange 2013 questions with an Exchange MVP.

All from the convenience of your home/office, on September 12, 2013!

Discover answers to questions like:
- What are the key features of Exchange 2013?
- How can we secure and better control our Exchange environment?
- What are 5 strategies to better manage Exchange for 2013 and beyond?

This unique, online conference is limited to 1,000 participants, so register now if you have not already done so, register here.

How to Configure Public and Private Computer Settings in OWA 2013

The new Exchange 2013 Outlook Web App (OWA) logon page no longer allows users to select whether they are using a public or a private computer. By default, OWA 2013 assumes users are using a private computer the default timeout of 8 hours is used. This timeout specifies how long a user can be inactive before requiring him/her to sign in again.

The LogonPagePublicPrivateSelectionEnabled parameter in the Set-OWAVirtualDirectory cmdlet specifies whether the OWA sign-in page includes this private/public computer sign-in option. While by default this parameter is set to True in Exchange 2010, in 2013 it is set to False. To change this on server CAS1, simply run the following cmdlets:

Set-OwaVirtualDirectory “CAS1\owa (Default Web Site)” -LogonPagePublicPrivateSelectionEnabled $True
IISreset /noforce

Similarly to previous versions of Exchange, the default timeout for private computers is still 8 hours for public computers 15 minutes. You can change this by running the following cmdlets to create the necessary registry keys:

Set-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Services\MSExchange OWA” -Name PrivateTimeout -Value "timeout_minutes" -Type DWORD

Set-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Services\MSExchange OWA” -Name PublicTimeout -Value "timeout_minutes" -Type DWORD

IISreset /noforce

Error Deleting Database "Failed to remove monitoring mailbox object"

When removing databases from Exchange 2013, you might get the following error if the correct procedures are not followed:

Failed to remove monitoring mailbox object of database “database_name”. Exception: Active directory operation failed on “server_name”. This error is not retrievable. Additional information: Access is denied. Active directory response: 000000005: SecErr: DSID-031520B2, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0.

In this case, the database was removed an Active Directory [AD] error (with a not very useful description) complaining about insufficient permissions is thrown. If you run:

Get-Mailbox -Monitoring

You will most likely see a warning regarding a corrupted Health Mailbox:

WARNING: The object “domain_name”/Microsoft Exchange System Objects/Monitoring Mailboxes/”Health_Mailbox_GUID” has been corrupted, and it's in an inconsistent state. The following validation errors happened: WARNING: Database is mandatory or UserMailbox.

Because Exchange 2013 did not have sufficient permissions to the domainname/Microsoft Exchange System Objects/Monitoring Mailboxes Organizational Unit [OU], it could not delete the AD objects related to the database’s health mailboxes. In this case, the database attribute is null because the database the health mailbox references no longer exists.

To fix this issue, simply delete the health mailboxes referenced by the error(s) from that OU by using Active Directory Users and Computers. After removing these, the warning should be gone.

Deleting health mailboxes is a low risk procedure because they will be automatically re-created by the Microsoft Exchange Health Manager service on the Exchange 2013 server hosting the database when this service is restarted.

Exchange Cmdlet Extension Agents

Cmdlet Extension Agents are Exchange components that are invoked by cmdlets when the cmdlets run. These agents are available on any server role and, as the name suggests, they extend the capabilities of cmdlets that invoke them by assisting in processing data or performing additional actions based on the requirements of the cmdlet. They can be used to modify, replace or extend functionality of any Exchange cmdlet. For example, they can override a value provided by a user, perform actions outside of the cmdlet workflow, provide a value for a required parameter that was not provided, etc.

An example of such functionality is when creating a new mailbox. If an administrator does not specify a mailbox database when creating a new mailbox with Exchange 2007, the process fails. However, in Exchange 2010 and 2013, the New-Mailbox cmdlet invokes the Mailbox Resources Management agent whenever it is run. If a database is not specified, this agent automatically determines a suitable database on which to create the new mailbox and inserts that value into the Database parameter.

Note that cmdlet extension agents can only be invoked by Exchange 2010 and 2013 cmdlets as they are a feature introduced in Exchange 2010. Scripts cannot invoke these agents directly but if they contain Exchange 2010/2013 cmdlets, those cmdlets continue to call the cmdlet extension agents.

Unfortunately, cmdlet extension agents are not a well-known feature and, therefore, are often overlooked or ignored. A good example is the requirement that many organizations have to customize things immediately after creating a mailbox. They often develop custom scripts or even buy 3rd-party applications to achieve this, when cmdlet extension agents can very well be used to achieve most, if not all, these requirements.

In this article I use a particular cmdlet extension agent, called Scripting agent, in order to customize the mailbox provisioning process. Specifically, when a new mailbox is created, the agent will automatically configure archiving, permissions, Single Item Recovery, ActiveSync, other user attributes such as country and city, and send a welcome e-mail to the user.

To continue reading, please check the Cmdlet Extension Agents article on MSExchange.org.

 

Hyper-V Replica with Exchange Supportability

If you are considering whether to use Hyper-V Replica with Exchange, remember that Exchange has its own disaster recovery and site awareness capabilities that should be used instead.

 

Hyper-V Replica is not needed and is not supported because of problems with Exchange roles being forced back in time in the event of an unplanned failover.

DirSync Error "Microsoft.Online.PasswordSynchronization.Cryptography.dll Could Not Be Loaded"

The Directory Synchronization Tool (DirSync) is supported on Windows Server 2008 SP1 and higher. However, the Password Sync feature introduced in the latest version will not function correctly if installed on an OS older than Windows Server 2008 R2 SP1 (Windows Server 2008 R2 SP1 itself is supported).

When this is the case, you will receive the following error:

Password synchronization failed for domain: "your domain".
Details: System.IO.FileLoadException: A procedure imported by 'Microsoft.Online.PasswordSynchronization.Cryptography.dll' could not be loaded.

To resolve this issue, install the Directory Sync tool on a supported Windows Server OS.

eDiscovery During Exchange 2010/2013 Coexistence

When transitioning from Exchange 2010 to 2013, you should be aware of the following in regarding to the eDiscovery feature during the coexistence period.

 

Administrator audit logs and metadata for eDiscovery searches (not search results) are stored in a system (arbitration) mailbox name SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9} with the display name of Microsoft Exchange.

 

For eDiscovery to work during the period while Exchange 2010 and 2013 coexist (and after the transition), you need to move this system mailbox to an Exchange 2013 server. You can do this using the EAC or through PowerShell:

Get-Mailbox -Arbitration "SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}" | New-MoveRequest -TargetDatabase “Exchange_2013_database”

When the move finishes, to check if everything went OK, run the following cmdlet and ensure the Server and Database values refer to Exchange 2013:

Get-Mailbox -Arbitration “SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}” | FL ServerName, Database

If you do not move this system mailbox to Exchange 2013, the following issues will occur when Exchange 2010 and Exchange 2013 coexist in your Exchange organization:

• Exchange 2013 tasks are not saved to the administrator audit log. When you run the Search-AdminAuditLog cmdlet or try to export the administrator audit log in the EAC, you will receive an error that says you cannot create an administrator audit log search because this system mailbox is located on a server that is not running Exchange 2013. A Microsoft Exchange error with an Event ID of 5000 is also logged in the Windows Application log each time a command is run;
• You cannot run eDiscovery searches using the EAC or the Shell in Exchange 2013. Mailbox searches can be created and queued, but they cannot be started. An error with an Event ID of 6 is logged in the MsExchange Management log, stating that the Start-MailboxSearch cmdlet failed. However, you can search mailboxes using the Shell and the Exchange Control Panel in Exchange 2010.

Exchange 2013 “Please restart the Microsoft Information Store service”

With Exchange 2013 Cumulative Update 1, administrators will notice that every time a new database is added, they are prompted to restart the Information Store service. Although this was also true in Exchange 2013 RTM, the difference was that before administrators did not receive this restart warning.

 

As we saw previously, Exchange 2013 introduced the new Managed Store, which uses a different memory management model than previous editions of Exchange. With a Store Worker Process for each active and passive database present on a server, it is now required to restart the Information Store service because the Store only determines the amount of memory that it will use to manage each database when it starts (which happens when the server starts or when the Information Store service is restarted).

 

In previous editions, Exchange typically seizes as much memory as it is available on a server and uses that memory to cache Store data. In Exchange 2013 this approach was revised and it now calculates how much memory it should use and makes it available to worker processes (obviously active databases are assigned more memory than passive databases). However, this new memory management approach depends on knowing how many worker processes are in use. When databases are added from a server, the Store does not re-calculate the amount of RAM for each worker process dynamically. This does not mean that you cannot mount the new database – it means caching will not be as efficient as it should be until the next time the Store process restarts and memory use is adjusted.

This might be seen as a big drawback of Exchange 2013, and it might even change in the future, but adding or removing databases should not happen that often, so the impact should not be that massive.

Differences Between FOPE and EOP

When customers using Forefront Online Protection for Exchange (FOPE) are upgraded to Exchange Online Protection (EOP), including Exchange Online and FOPE-standalone customers, there are behavior changes and feature differences to take note of, such as:

 

Quarantine access - In FOPE, end users and administrators could access the FOPE quarantine. In EOP, only administrators can access the EOP quarantine in the Exchange admin center. However, end users can self-manage their own spam-quarantined messages via end-user spam notifications;

 

Deferral notifications - FOPE could be configured to notify an administrator if an inbound message was deferred by the service. EOP does not currently have deferral notifications;

 

Multiple domain support - In FOPE, you used virtual domains to configure policy rules to apply to a specific group and route messages to a specific site. In EOP, you can route messages to a specific site by using transport rules and connectors. For instance, you can create an Outbound connector with criteria based routing enabled to deliver messages to a specific site. You can select this connector for use in a transport rule that is triggered based on a particular attribute in the transport rule predicate, such as the City property type;

 

Directory synchronization - The Office 365 DirSync tool replaces the FOPE DirSync tool;

 

Directory-Based Edge Blocking - In FOPE, the Directory-Based Edge Blocking feature enables administrators to reject email going to non-existent users in their organization rather than accept the message and try to deliver it or send it to the spam quarantine. In EOP, Directory-Based Edge Blocking is currently not supported;

 

Partner and reseller administration - If you are a Microsoft partner or reseller, and you sell EOP to your customers, you can request permission to administer their account within the Office 365 admin center. This is known as delegated administration, and it allows you to configure their EOP settings as if you were an administrator within their organization. (In the new Office 365, there isn’t a separate user interface for company administration.);

 

Connection filter IP Allow list - In FOPE, the IP Allow list was respected end-to-end only for single IP addresses. EOP's IP Allow list is respected end-to-end for single IP addresses and CIDR ranges from /32 to /24. For example, 65.55.39.10/26;

 

FOPE connectors and spam filtering - When you created or edited a FOPE connector, you could make selections to bypass spam filtering and policy-rule filtering. In EOP, you can't configure a connector to bypass filtering. Instead, Microsoft recommends that you use the connection filter's IP Allow list to bypass all spam and policy filtering;

 

Disabling anti-malware protection - The FOPE Administration Center allowed you to disable malware filtering. In EOP, malware filtering is automatically enabled for all customers. There is no way to disable it;

 

Exchange Enterprise CAL with Services - If you are an Exchange Enterprise CAL with Services customer, and you use EOP to protect your on-premises mailboxes, two additional features are available to you: Data Loss Prevention (DLP) and Remote Windows PowerShell administration. DLP helps you identify, monitor, and protect sensitive information in your organization through deep content analysis. Using Remote Windows PowerShell, you can manage your cloud features by running scripts from the command line. There is more information about EECAL with Services licensing and its included features in the Exchange Online Protection Overview.

 

Source: Office 365 Community

 

Migrating Public Folders to Exchange 2013

Now that Exchange 2007 SP3 RU10, Exchange 2010 SP3 and Exchange 2013 CU1 have been released, administrators can start deploying Exchange 2013 in a coexistence scenario with these two previous versions of Exchange.

 

Part of many transitions from Exchange 2007/2010 to 2013 will include the migration of Public Folders (PFs). Because of all the major changes made to PFs, discussed in the Exchange 2013 Preview - Public Folders article, legacy Exchange mailboxes are unable to access the PF hierarchy on Exchange 2013 servers. However, mailboxes on Exchange 2013 can connect to legacy PFs.

 

Unlike migrating PFs between previous versions of Exchange, PFs on Exchange 2013 and legacy PFs cannot coexist in an Exchange organization, which means that migrating PFs to Exchange 2013 is a one-time cut-over process.

 

Because legacy mailboxes cannot access PFs in Exchange 2013, it is recommended that all mailboxes are first moved to Exchange 2013 and only then PFs migrated.

 

The high level process for migrating Public Folders from Exchange 2007/2010 is as follows:
   1. Migrate user mailboxes to Exchange 2013 before migrating PFs;
   2. Snapshot current PF environment for comparison when migration is complete (folders, sizes and permissions);
   3. Create CSV file, manually or using scripts (Export-PublicFolderStatistics.ps1 and PublicFolderToMailboxMapGenerator.ps1). End result is a CSV file mapping PFs to new PF mailboxes;
   4. Create PF mailboxes using New-Mailbox –PublicFolder cmdlet;
   5. Migrate PF content using New-PublicFolderMigrationRequest cmdlet;
   6. Lock down Exchange 2007/2010 PFs for final migration using the following cmdlets:
         a.      Set-OrganizationConfig –PublicFoldersLockedForMigration $True (Exchange 2010)

         b.      Set-OrganizationConfig –PublicFolderMigrationComplete $True (Exchange 2013)

         c.      Set-PublicFolderMigrationRequest <name> -PreventCompletion $False (Exchange 2013)

         d.      Resume-PublicFolderMigrationRequest <name> (Exchange 2013)

   7. Test new PFs;
   8. Snapshot Exchange 2013 PFs and compare with Exchange 2007/2010 PF snapshots;
   9. Roll back, if necessary, by running Set-OrganizationConfig –PublicFoldersLockedForMigration $False and Set-OrganizationConfig –PublicFolderMigrationComplete $False;
   10. Remove Exchange 2007/2010 PFs and PF databases.

For a detailed explanation, including step by step instructions, please check MSExchange.org and the Migrating Public Folders to Exchange 2013 article.

Update-MailboxDatabaseCopy in Exchange 2013 CU1

The Update-MailboxDatabaseCopy cmdlet is used to seed or reseed a mailbox database copy. Seeding is the process in which a copy of a mailbox database is added to another Mailbox server, thus becoming the database copy into which copied log files and data are replayed. This cmdlet can also be used to seed a content index catalog for a mailbox database copy.

In Exchange 2013 CU1 this cmdlet includes some new parameters that are designed to aid with automation of seeding operations. These parameters include:

• BeginSeed – this is useful for scripting reseeds. With this parameter, the task asynchronously starts the seeding operation and then exits the cmdlet;
• MaximumSeedsInParallel – this is used with the Server parameter to specify the maximum number of parallel seeding operations that should occur across the specified server during a full server reseed operation. The default value is 10;
• SafeDeleteExistingFiles – this is used to perform a seeding operation with a single copy redundancy pre-check prior to the seed. Because this parameter includes the redundancy safety check, it requires a lower level of permissions than the DeleteExistingFiles parameter, enabling a limited permission administrator to perform the seeding operation;
• Server – this is used as part of a full server reseed operation to reseed all database copies in a Failed and Suspended state. It can be used with the MaximumSeedsInParallel parameter to start reseeds of database copies in parallel across the specified server in batches of up to the value of the MaximumSeedsInParallel parameter copies at a time.

Remember that you must suspend a database copy before you can update it using the Update-MailboxDatabaseCopy cmdlet.

DirSync Password Synchronization

The latest version of the Windows Azure Active Directory (WAAD) Sync Tool, also known as DirSync, has just been released.

Besides supporting Windows Server 2012, this new version provides the much anticipated Password Sync feature, which enables users to log into their Azure Active Directory services (such as Office 365, InTune, CRM Online, etc.) using the same password as they use to log into their on-premises network.

However, this should not be seen as a replacement for ADFS. Rather, it is an alternative for organizations that find it sufficient to have users using the same password in Office 365 as in the on-premises Active Directory. ADFS provides many other features that this tool does not, one of them being Single-Sign On (SSO) where users only need to authenticate once when they are logged on to a domain-joined client machine. With this new tool, and without ADFS, users will get prompted for credentials when accessing Office 365 resources even if they are on a domain-joined machine. The advantage is that the username and passwords are the same, and when users update their credentials on Active Directory, the password will get synchronized to WAAD. This tool does not provide SSO because there is no token sharing/exchange in the Password Sync based process.

How Password Sync Works
The Active Directory Domain Service stores passwords in form of a hash value representation of the actual user password. The Password hash cannot be used to login to an on-premises network and it is also designed so that it cannot be reversed in order to gain access to the user’s plaintext password. To synchronize a password, the Directory Sync tool extracts the user password hash from the on-premises Active Directory. Additional security processing is applied to the password hash before it is synchronized to the Azure Active Directory Authentication service. The actual data flow of the password synchronization process is similar to the synchronization of user data such as DisplayName or Email Addresses.

Passwords are synchronized more frequently than the standard Directory Sync window for other attributes. Passwords are synchronized on a per-user basis and are generally synchronized in chronological order. When a user’s password is synchronized from the on-premises AD to the cloud, the existing cloud password will be overwritten.

When the Password Sync feature is first enables in DirSync, it will perform an initial synchronization of the passwords of all in-scope users from the on-premises Active Directory to Azure Active Directory. You cannot explicitly define the set of users that will have their passwords synchronized to the cloud. Subsequently, when an on-premises user changes their password, the Password Sync feature will detect and synchronize the changed password, most often in a matter of minutes. The Password Sync feature will automatically retry failed user password syncs. If an error occurs during an attempt to synchronize a password the error is logged in event viewer.

The synchronization of a password has no impact on currently logged on users. If a user that is logged into a cloud service also changes their on-premise password, the cloud service session will continue uninterrupted. As soon as the cloud service session expires, the user has to re-authenticate using the new password.

Security Considerations
When synchronizing passwords using the password sync feature, the plain text version of a user’s password is neither exposed to the password sync tool nor to Azure AD or any of the associated services. Additionally, there is no requirement on the on-premises Active Directory to store the password in a reversibly encrypted format. A digest of the Windows Active Directory password hash is used for the transmission between the on-premises AD and Azure Active Directory. The digest of the password hash cannot be used to access resources in the customer's on-premises environment.

Password Policy Considerations
There are 2 types of password policies that are affected by enabling password sync:

• Password Complexity Policy: when you enable password sync, the password complexity policies configured in the on-premises Active Directory override any complexity policies that may be defined in the cloud for synchronized users;
• Password Expiration Policy: if a user is in the scope of the password sync feature, the cloud account password is set to "Never Expire". This means that it is possible for a user's password to expire in the on-premises environment, but they can continue to log into cloud services using this expired password. The cloud password will be updated the next time the user changes the password in the on-premises environment.

Enabling Password Sync
Password Sync is enabled when running the Directory Sync tool Configuration Wizard. When prompted by the Wizard, select the “Enable Password Sync” checkbox. This process will trigger a full synchronization which generally takes longer than other sync cycles to complete.

NOTE: DirSync is supported on Windows Server 2008 SP1 and higher. However, the Password Sync feature will not function correctly if DirSync is installed on an OS older than Windows Server 2008 R2 SP1 (Windows Server 2008 R2 SP1 itself is supported).

 

The new version of DirSync (v1.0.6385.0012) can be downloaded from your respective Office 365 Admin portal or from here.

Exchange 2013 Management Pack

The Exchange team has just released the Exchange 2013 Management Pack! You can find the Management Pack here and the guide here. The guide walks through the details of deploying, configuring and using the Management Pack.

 

Prerequisites
Before you can import the management pack, verify that the following conditions are met:

  • You have one of the following versions of System Center Operations Manager deployed in your organization:

        o System Center Operations Manager 2012 RTM or later

        o System Center Operations Manager 2007 R2 or later

  • You have already deployed SCOM agents to your Exchange Servers. Show me how.

  • The SCOM agents on your Exchange Servers are running under the local system account. Show me how.

  • The SCOM agents on your Exchange Servers are configured to act as a proxy and discover managed objects on other computers. Show me how.

  • Your user account is a member of the Operations Manager Administrators role.

 

Management Pack Scope and Benefits
The Exchange team takes monitoring seriously, and they have created a pretty comprehensive Management Pack in terms of monitoring coverage, with the primary focus being reduced downtime for an Exchange environment.

 

The Management Pack contains about 75 monitors that cover Exchange component health (such as Hub Transport health), customer touch point health (such as “is OWA working”), clustered scenarios, as well as dependencies monitoring (“is Active Directory healthy”). Monitoring covers primarily availability and performance scenarios.

 

The Exchange 2013 product comes with monitoring “built in” (more on that below). This means that Exchange itself has means to detect and try to automatically recover from availability and performance issues, before an operator is notified. This means reduced alert noise, as well as reduced administrative overhead for the Exchange product itself. In concrete terms, an Exchange server may detect an issue, then try for some time to fix it automatically. Only after the automatic recovery attempts have failed is the operator notified via an alert.

 

What’s in the Management Pack?
The Management Pack is very simple. It contains a handful of classes, 3 views, and about 75 monitors described here. There are also some dependency monitors.

 

All the monitors are simple event-based monitors using events in the Microsoft-Exchange-ManagedAvailability/Monitoring event log, logged by each Exchange server. So, each Exchange server is responsible for monitoring itself and its health.

 

In terms of scalability, this means this Management Pack will have a low impact to your Operations Manager environment. You will not require a separate Management Group for this MP for scalability purposes.

 

Where are the monitors?

If you look at the Management Pack in some tool like MP Viewer, you will discover that there are not 75 monitors in the Management Pack. This is because the Management Pack has logic to dynamically determine the set of monitors by communicating with the built-in monitoring features of Exchange (more on that below). The way to see the monitors is by installing the Management Pack in an Operations Manager environment with monitored Exchange servers and using Health Explorer (you can also see them listed in the Management Pack Guide).

 

What’s not in the Management Pack?
If you are familiar with the Exchange 2010 Management Pack, you know that it had a service called the correlation engine that ran on the Root Management Server. It basically correlated health data from all monitored Exchange components. In the Exchange 2013 Management Pack, the correlation engine is no longer used. Each monitored Exchange server is responsible for monitoring its own health, and simply reports this via the Operations Manager agent. There is a little bit of roll-up going on, from Exchange server to Organization health. There are no special components running on the Operations Manager Management Servers.

 

The Exchange 2010 Management Pack had tens of classes, leading to a pretty complex health model and many object instances being created. The Exchange 2013 Management Pack is very simple. It has only a few classes and should have a very low impact on Operations Manager in terms of instance space.

 

There are no performance counters collected by this Management Pack (as mentioned above, the monitoring does cover performance scenarios). However, all Exchange PerfMon counters are still available. It should be simple to create your own performance collection rules, if you do require them.

 

This means that by default there is way less pressure on the Management Group compared to the Exchange 2010 Management Pack, since there are no performance counters to store. But, what about reporting? There are also no reports in this Management Pack. However, you can use some of the built-in Operations Manager reports (such as the Health report) to track organization availability, or define SLAs against the Organization.

 

How does the Management Pack work?
Exchange 2013 has a built in monitoring engine called Managed Availability. It runs on every Exchange server. It contains logic for how to determine Exchange health. It detects issues, automatically performs recoveries (Exchange calls these “responders”) and ultimately notifies operators of issues, if the recoveries were not successful. The purpose of this of course, is high availability. Managed Availability is explained in more detail here.

 

 

Notification/Alerting to Operations Manager is handled via events, so the Management Pack has a set of simple event monitors that trigger based on these events. Events are logged to the Microsoft-Exchange-ManagedAvailability/Monitoring event log.

 

  • Probes: these are sets of data collectors that measure various components. There are three distinct types of probes:

      o Synthetic transactions that measure synthetic end-to-end user operations and checks that measure actual traffic;

      o Checks that measure actual customer traffic;

      o Notifications that allow Exchange to take immediate action. A good example of this is the notification that is triggered when a certificate expires.
  • Monitors: the data collected by probes are passed on to monitors that analyze the data for specific conditions and depending on those conditions determine if the particular component is healthy or unhealthy;
  • Responders: if a monitor determines that a component is unhealthy, it will trigger a responder. If the problem is recoverable, the responder attempts to recover the component using the built-in logic. There are several responders available for each component, but the one responder that’s relevant for the Exchange 2013 Management Pack is the Escalate Responder. When the Escalate Responder is triggered, it generates an event that the Exchange 2013 Management Pack recognizes and feeds the appropriate information into that alert that provides administrators with the information necessary to address the problem.

Each component in Exchange 2013 uses a specific set of probes, monitors and responders to monitor itself. These collections of probes and monitors are referred to as health sets. For example, there are a number of probes that collect data about various aspects of the ActiveSync service. This data is processed by a designated set of monitors that trigger the appropriate responders to correct any issues that they detect in the ActiveSync service. Collectively, these components make up the ActiveSync health set.

How should I work with this Management Pack?
First of all, this Management Pack should be simple to implement from an Operations Manager perspective. There are no special components to install on Management Servers, you do not need to worry about the impact to the Management Group in terms of database size, instance space, Management Server workload etc. You should be fine just importing this MP into your existing environment also for large Exchange deployments (as usual, we do recommend gradual deployment just in case). The Management Pack Guide includes a chapter on deployment, as usual you will need to enable Agent Proxy when you install the Operations Manager agents on Exchange 2013 servers.

 

Also, the Exchange team has been using the same monitoring logic in the Office365 environment. Normally, few changes to the Management Pack should be required.

 

If you want to disable some monitor, you can just create an override in Operations Manager as usual.

 

If you want to change a threshold for some monitor, this is done in the Exchange Managed Availability engine via PowerShell cmdlets. This does not involve Operations Manager at all. The Exchange Management Pack Guide walks through this scenario in some detail here. Since this kind of override is a modification of Exchange behavior, this kind of override is most commonly done by the Exchange administrator.

 

Also, Exchange Cumulative Updates may contain new or updated monitoring logic. These should be reviewed to determine the impact of that updated logic.

 

In terms of interoperability, this Management Pack does not upgrade the Exchange 2010 Management Pack, this is a completely new MP. It is possible to run these Management Packs side-by-side as you upgrade your Exchange environment from 2010 to 2013.

 

What’s the update mechanism for this Management Pack?The Managed Availability feature is built in to Exchange 2013. It contains the logic for how to detect issues and how to recover from them. The results of that is then reported to the event log for Operations Manager to pick up via event monitors. This means that updates in terms of Managed Availability monitors are shipped with Exchange Cumulative Updates.

As mentioned previously, the Exchange 2013 Management Pack has functionality to automatically detect these changes, so typically no Management Pack update is required.

 

Sources

  • Microsoft Exchange Server 2013 Management Pack
  • MP Blog: Exchange 2013 Management Pack released
  • Exchange Server 2013 Management Pack Guide

Office 365 Generic MX Records Deprecated

Microsoft has changed how e-mail is routed to Office 365 in order to provide continuing improvements in performance and reliability, and to make e-mail routing more efficient. Now, each custom domain in Office 365 has its own unique Mail Exchange (MX) record value.

Up until recently, MX records for custom domains were “generic”, meaning everyone would point the MX record for their particular domain(s) to a generic MX record such as mail.global.frontbridge.com or something similar, without any reference to the organization. These generic MX records were deprecated on 1 January 2013 and support for these records will end on 1 July 2013. As such, organizations need to update their MX records to domain-specific MX records before July.

Please note that this does not affect P1 user plans, but all E plans.

You can find the specific value(s) for your domain(s) in the domain administration section of your Office 365 tenant admin page. The values are also listed in an e-mail your organization’s technical contact should have received from Microsoft.

Login to the Office 365 portal as an administrator, click on Domains under Management on the left hand side:

Select the domain you want to update the MX records for and click on View DNS settings:

Click on View DNS records:

Scroll down until Exchange Online. In here, look for the Points to address field for MX: 

This should be in the format of “company-domain”.mail.eo.outlook.com.


If you do not update all your generic MX records by 1 July 2013, you may not receive a future update, resulting in a mail flow disruption from people outside your organization. Microsoft cannot predict when or if such an update will occur. Even though generic records will be unsupported after this date, Microsoft will e-mail customers if they know of such an update in advance.

Exchange 2013 Managed Availability

In Exchange 2013, native, built-in monitoring and recovery actions are included in a feature called Managed Availability. Managed Availability is the integration of built-in, active monitoring and the Exchange 2013 high availability platform, allowing Exchange to make a determination on when to fail over a database based on service health.

To view the health of a server, you use the cmdlets Get-ServerHealth to retrieve the raw health data and Get-HealthReport that operates on the raw health data and provides a snapshot of the health.

This example returns the server health for server MBX1:

Get-ServerHealth MBX1

The following examples return a report on the health of the server. The second cmdlet narrows this report to the Store process:

Get-ServerHealth | Get-HealthReport
Get-ServerHealth | Where {$_.HealthSetName -eq “Store”} | Get-HealthReport