Monday, November 4, 2013

Exchange 2013 DAG with Dynamic Quorum

Windows Server 2012 introduced a new quorum model called Failover Clustering Dynamic Quorum, which we can use with Exchange. When using Dynamic Quorum, the cluster dynamically manages the vote assignment to nodes based on the state of each node. When a node shuts down or crashes, it loses its quorum vote. When a node successfully re-joins the cluster, it regains its quorum vote. By dynamically adjusting the assignment of quorum votes, the cluster can increase or decrease the number of quorum votes that are required to keep it running. This enables the cluster to maintain availability during sequential node failures or shutdowns.
 
With a dynamic quorum, the cluster quorum majority is determined by the set of nodes that are active members of the cluster at any time. This is an important distinction from the cluster quorum in Windows Server 2008 R2 where the quorum majority is fixed, based on the initial cluster configuration.
 
The advantage this brings, is that it is now possible for a cluster to run even if the number of nodes remaining in the cluster is less than 50%! By dynamically adjusting the quorum majority requirement, the cluster can sustain sequential node shutdowns down to a single node and still keep running. It does not allow the cluster to sustain a simultaneous failure of a majority of voting members though. To continue running, the cluster must always have a quorum majority at the time of a node shutdown or failure.
 
 
The following picture shows a DAG still operational even though two out of three servers are offline:
 
 
To read more about this feature, including tests with an Exchange 2013 DAG, please check my Exchange 2013 DAGwith Dynamic Quorum article on MSExchange.org.

Friday, November 1, 2013

Last Logon Information in Exchange 2013

If we want to check when a user last logged on to their mailbox in Exchange 2007 and 2010 we have to use the Exchange Management Shell [EMS] and the following cmdlet:
Get-MailboxStatistics "User" | Select LastLoggedOnUserAccount, LastLogonTime

Note that the LastLoggedOnUserAccount property indicates the account last used to log on to the mailbox. This could be a user with FullAccess permissions to the mailbox, a delegate or even someone simply checking the user’s Calendar!
 
With Exchange 2013 part of this information is now available through the Exchange Administration Centre as well. If you:
    1.       Navigate to Recipients and then Mailboxes;
    2.       Double-click on the user you want to check this information for;
    3.       Select the Mailbox Usage tab and in there you will see the Last Logon date and time.

However, to check who actually logged on, we still need to use the EMS...

Monday, October 14, 2013

Office 365 Network Analysis Tool

With BPOS and the first iteration of Office 365, Microsoft provided the Speed Test web tool to assist in determining if an organization’s internet connection could support Microsoft Online services, mainly focusing on Exchange Online and Lync Online. This tool was available from www.microsoftspeedtest.com.

However, for some reason, this tool has not been available for many months now, leaving organizations and IT professionals without a tool to evaluate the impact of Microsoft Online services on their internet connection.

Fortunately, the Office 365 Network Analysis Tool is now available! Similar to Speed Test, this new tool is also web-based and runs several checks such as port connectivity, route paths between the client and tenant, bandwidth speed and capacity tests, and VoIP readiness. At the end of the test the tool generates a nice report.
 
This tool can be found at:
North America
   http://na.deployoffice365.com (URL not yet available)
   http://na1-fasttrack.cloudapp.net

EMEA
   http://emea.deployoffice365.com (URL not yet available)
   http://em1-fasttrack.cloudapp.net

APAC
   http://apac.deployoffice365.com (URL not yet available)
   http://ap1-fasttrack.cloudapp.net




Thursday, October 10, 2013

How to Trigger a Full Password Sync in DirSync

In Windows Azure Active Directory Synchronization Tool (or DirSync), a full Password Sync and a full Directory Sync are two different events. A full Password Sync synchronizes password hashes for all DirSync users, while a full Directory Sync does not trigger a full password sync. By default, the only activity that triggers a full password sync is completing the DirSync’s Configuration Wizard.

But there is a way around this. In order to trigger a full password sync, perform the following steps (you must be using DirSync v6438.0003 or above):
  1. On the DirSync server, run the following .psc1: C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1;
  2. In the new Powershell console, run Set-FullPasswordSync;
  3. Now load the services console by running Services.msc;
  4. Restart the Forefront Identity Manager Synchronization Service Service.

Once this is complete, you should see a series of 656 EventIDs (Password Sync Requests) and 657 EventIDs (Password Sync Results) indicating that a full password sync was triggered.

Wednesday, October 2, 2013

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:

Monday, September 23, 2013

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!

Monday, September 9, 2013

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

Tuesday, September 3, 2013

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.
 

Sunday, September 1, 2013

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.

Tuesday, August 13, 2013

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

Sunday, August 4, 2013

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.

Tuesday, July 30, 2013

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.
 

Friday, July 26, 2013

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.

Saturday, July 13, 2013

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.

Tuesday, July 2, 2013

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.

Thursday, June 27, 2013

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.
 
 

Monday, June 17, 2013

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.

Thursday, June 13, 2013

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.