Office 365 for business public roadmap

The Office 365 for business roadmap lists updates that are currently planned for applicable subscribers. Updates are at various stages from being in development to rolling-out to customers to being generally available for applicable customers world-wide. Expand an update to learn more about it and click the learn more link to read more details.

To view the Office 365 roadmap click here.

Learn more about Office 365 for business service updates here.

Import Certificates via PowerShell

If you’re like me I have to play with a lot of labs. I often use the same domain names to make my certificate life a little easier to manage. Maybe you just need to import certificates on a lot of servers. Either case this little snippet will make your certificate life a little easier :-).

  
      Welcome to the Exchange Management Shell!


VERBOSE: Connecting to Exchange Server.
VERBOSE: Connected to Exchange Server.

[PS] C:\PowerShell>$pfxpath = “C:\Certificates\contoso.com.pfx”
[PS] C:\PowerShell>$password = “MyPasswordIsSecure”
[PS] C:\PowerShell>Add-Type -AssemblyName System.Security
[PS] C:\PowerShell>$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
[PS] C:\PowerShell>$cert.Import($pfxpath, $password, ‘Exportable’)
[PS] C:\PowerShell>$cert
 

Update-DatabaseSchema cmdlet

The Update-DatabaseSchema cmdlet is designed to safely upgrade database schema in a DAG deployment. Unlike previous releases, a database schema upgrade in Exchange 2013 can only occur after all DAG members are upgraded to a version of software that supports the schema version and there is control over when the schema upgrade occurs. This design prevents issues like those encountered during upgrades of Exchange 2010 DAG members that automatically upgraded the database schema version when mounting database on an upgraded server and prevented you from being able to mount the database on a server that has not yet been upgraded.

More Reading: Microsoft Exchange Team Blog
Cmdlet Information: Update-DatabaseSchema

How to restore In-Place Hold and Litigation Hold settings in an Exchange 2013 hybrid deployment

In an Exchange Server 2013 hybrid deployment with or without on-premises Lync Server 2013
Restore In-Place Hold settings

To restore In-Place Hold settings, follow these steps:

  1. On the Exchange 2013 server, open the Exchange Admin Center by using on-premises admin credentials. 
  2. If your organization is enabled for a hybrid deployment with Exchange Online in Office 365, click the Enterprise tab in the navigation bar.

    Collapse this imageExpand this image

    Screen shot of the navigation bar in the Exchange Admin Center

     

  3. Click compliance management, and then click in-place eDiscovery & hold.

    Collapse this imageExpand this image

    Screen shot of the in-place eDiscovery & hold page in the Exchange Admin Center

     

  4. Select the In-Place Hold entry for which you want to restore In-Place Hold settings. Double-click it, or click Edit (

    Collapse this imageExpand this image

    2934402

    ), to open the properties page.

    Collapse this imageExpand this image

    Screen shot of the properties page for an In-Place Hold entry

     

  5. On the properties page, click In-Place Hold. The In-Place Hold settings for the user are displayed.

    Collapse this imageExpand this image

    Screen shot of the In-Place Hold settings for a user

     

  6. Click to clear the Place content matching the search query in selected mailboxes on hold check box, and then click save.
  7. Reopen the same properties page, and then click In-Place Hold. Notice that the Place content matching the search query in selected mailboxes on hold check box is cleared.

    Collapse this imageExpand this image

    Screen shot of the In-Place hold settings for a user, showing that the "Place content matching the search query in selected mailboxes on hold" check box is cleared

     

  8. Click to select the Place content matching the search query in selected mailboxes on hold check box.
    Additionally, if you were using a time-based In-Place Hold, select Specify number of days to hold items relative to their received date, enter the duration, and then click save. Doing this restores any In-Place Hold settings that existed before the issue occurred.
  9. Repeat step 4 to step 8 for any other In-Place Hold entries that you have.
Restore Litigation Hold settings

To restore Litigation Hold settings, follow these steps:

  1. Open Exchange Management Shell, and connect to your on-premises Exchange Server 2013 deployment.
  2. To restore a user’s Litigation Hold duration setting, run the following command:
    Set-Mailbox <user> -LitigationHoldDuration <valueInDays>

    For example, to set NinaT’s Litigation Hold duration to 90 days, run the following command:

    Set-Mailbox NinaT -LitigationHoldDuration 90

     

  3. Repeat step 2 for each user whose Litigation Hold duration setting you want to restore.
In an Exchange Online deployment with on-premises Lync Server 2013, and is running the Windows Azure Active Directory Sync tool with hybrid enabled

To restore the Litigation Hold duration setting, follow these steps:

  1. Connect to Exchange Online by using remote PowerShell. For more info, go to Connect to Exchange Online Using Remote PowerShell

    (http://technet.microsoft.com/en-us/library/jj984289(v=exchg.150).aspx)

    .

  2. To restore a user’s Litigation Hold duration setting, run the following command:
    Set-Mailbox <user> -LitigationHoldDuration <valueInDays>

    For example, to set NinaT’s Litigation Hold duration to 90 days, run the following command:

    Set-Mailbox NinaT -LitigationHoldDuration 90

     

  3. Repeat step 2 for each user whose Litigation Hold duration setting you want to restore.

After the next time that directory synchronization runs, the Lync 2013 server will pick up the restored Litigation Hold duration settings.

Source: Microsoft TechNet

"MigrationPermanentException" error when you move a mailbox from Exchange Online to an on-premises Exchange 2010 server in a hybrid deployment

PROBLEM

Assume that you have an Exchange hybrid deployment that includes on-premises Exchange 2010 servers. When you try to offboard or move a mailbox from Exchange Online to an Exchange 2010 server in your on-premises environment, you receive the following error message:

Error: MigrationPermanentException:
You shouldn’t migrate mailbox ‘<username>’ to Exchange 2010 or an earlier version while the user’s Instant Messaging contact list is stored in Exchange. If you do, the user could permanently lose access to their Instant Messaging contact list, which will cause serious data loss. The Exchange copy might be the only copy of this user’s contact list. To continue, please contact your Instant Messaging administrator and make sure that the user’s contact list is moved back to the Instant Messaging server. After this has been done, you should be able to complete this migration. If you must migrate the mailbox despite the potential data loss, you can do so by running ‎’Set-UMMailbox mailboxID -ImListMigrationCompleted $false‎’.

However, when you run the ‎Set-UMMailbox mailboxID -ImListMigrationCompleted $false‎ command as stated in the error message, you receive the following error message:

The Mailbox ‘<username>@contoso.com’ isn’t enabled for unified messaging.

CAUSE

This problem occurs if the Lync 2013 contacts of the user who is associated with the mailbox are stored in the unified contact store in Exchange. By default, if the user signed in to Lync 2013, the unified contact store is enabled for that user. Additionally, the user’s Lync contacts are migrated from the Lync server to Exchange.

SOLUTION

Use the Set-Mailbox cmdlet together with the ImListMigrationCompleted parameter instead of the ‎Set-UMMailbox cmdlet. For example, run the following command:

Set-Mailbox <username>@contoso.com -ImListMigrationCompleted $false

After you run the command, perform the mailbox move request.
Note The $false setting in the ImListMigrationCompletedparameter indicates that the user’s contacts haven’t been migrated to Lync to preserve the contact list. Be aware that the solution in this section may result in data loss. Exchange 2010 doesn’t support the unified contact store feature in Lync 2013. Therefore, if you move a mailbox back to Exchange 2010 while the user’s Lync contacts are stored in the unified contact store, the user could lose access to his or her Lync contacts. You should first make sure that the user’s Lync contacts are moved back to Lync server before you move the mailbox to Exchange 2010.

Source: Microsoft TechNet

"Performance counter updating error" after you install the Exchange Server 2013 Client Access server role

Symptoms

After you install the Microsoft Exchange Server 2013 Client Access server role on a new server and then restart the server, you receive many Event ID 106 errors in the Application log. For example, you may receive the following error message: ID: 106 Level: Error Source: MSExchange Common Machine: – Message: Performance counter updating error. Counter name is Per-Tenant KeyToRemoveBudgets Cache Size, category name is MSExchangeRemotePowershell. Optional code: 3. Exception: The exception thrown is: System.InvalidOperationException: The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly.\ When you check the Exchange Setup log (ExchangeSetup.log), you see the following information: [WARNING] The performance counter definition file C:\Program Files\Microsoft\Exchange Server\V15\Bin\Perf\AMD64\GlsPerformanceCounters.xml could not be found.

Cause

This issue occur because Exchange Server Setup tries to locate the GlsPerformanceCounters.xml performance counter definition file in the following folder: C:\Program Files\Microsoft\Exchange Server\V15\Bin\Perf\AMD64\ However, Exchange Server Setup should target the following folder instead: C:\Program Files\Microsoft\Exchange Server\V15\Setup\Perf Therefore, the performance counters cannot be loaded.

Resolution

To resolve this issue, use one of the following methods.

Method 1 Use a script to reload all the performance counters
  1. Copy the following script to Notepad, and then save the file as Perfcounters.ps1. Make sure that you change the “$path” value in the script if the Exchange Server is installed in a different location. (This script also applies to Exchange Server 2010.)
    add-pssnapin Microsoft.Exchange.Management.PowerShell.Setup
    $path = "C:\Program Files\Microsoft\Exchange Server\V15\Setup\Perf"
    $items = Get-ChildItem -Recurse $path
    
    $files = $items | ?{$_.extension -eq ".xml"} 
    
    Write-Host "Registering all perfmon counters in $path"
    Write-Host 
    
    $count = 0;
    
    foreach ($i in $files)
    {
       $count++ 
       $f =  $i.directory, "\", $i.name -join ""
    
       Write-Host $count $f -BackgroundColor red
    
       New-PerfCounters -DefinitionFileName $f
    }
  2. In Exchange Management Shell, run the file that you created in step 1. For example, run the following command:
    c:\perfcounters.ps1

Note Before you run the script, make sure that the execution policy is set to unrestricted. For more information about execution policies, go to the following Microsoft TechNet website: Using the Set-ExecutionPolicy Cmdlet (http://technet.microsoft.com/en-us/library/ee176961.aspx)

Method 2: Load the missing counters manually
  1. Close Performance Monitor, and then stop any other monitoring services that might be trying to use the missing counters.
  2. In Exchange Management Shell, type the following command, and then press Enter.
    Add-Pssnapin Microsoft.Exchange.Management.PowerShell.Setup
  3. Run New-PerfCounters to add the performance counters. For example, if you want to load the performance counters that are defined in GlsPerformanceCounters.xml, run the following cmdlet:
    New-PerfCounters –definitionfilename “C:\Program Files\Microsoft\Exchange Server\V15\Setup\Perf\GlsPerformanceCounters.xml
Source: Microsoft TechNet

Exchange 2003 Public Folder Replication Guided Walk Through (GWT)

Just in case you have not seen it, myself and several other engineers have worked hard on the Guided Walk Through (GWT) for Public Folder Replication.  Please check it out on http://support.microsoft.com/KB/842273.

You can read more about it on The Exchange Team Blog at http://blogs.technet.com/b/exchange/archive/2012/11/12/public-folder-replication-troubleshooter.aspx

Source: My Microsoft TechNet Blog