# Prepare the session #

###########################################################################

# Reference https://msdn.microsoft.com/en-us/library/windowsazure/jj152841.aspx

# Get Subscription GUID & Certificate hash from the Management portal.

# Management Portal > Settings > Subscriptions > Subscription ID

# Management Portal > Settings > Management certificates > Thumbprint ( This should match the publish file used in the earler command )

$subid = "xxxxxxxxxxxxxxxxxxxxxx"

$cert = Get-Item Cert:\CurrentUser\My\xxxxxxxxxxxxxxxxxx

Set-AzureSubscription -SubscriptionName "contosotestlab" -SubscriptionId $subid -Certificate $cert

Select-AzureSubscription -SubscriptionName contosotestlab

Methods of activating Office 2013

1.      Multiple Activation Key (MAK)

MAK activates systems on a one-time basis, using Microsoft's hosted activation services, either via the Internet or by telephone. This is the traditional way we know of activating office.

Sub divided into MAK Independent activation & MAK proxy activation.

2.      Key Management Service (KMS).

A client-server model in which you must install and activate a KMS host activation key on a KMS host computer. This establishes a local activation service in your environment. Office 2013 client computers connect to the local Office 2013 KMS host for activation on an on-going basis.

3.      Active Directory-based activation of Office 2013

Active Directory-based activation can activate all Office 2013 volume license clients throughout a domain. Active Directory-based activation is available only for Office 2013 on Windows 8 and Windows Server 2012.

Types of Serial keys involved

1.      Office 2013 Multiple Activation Key (MAK)

The MAK activation is used for one-time activation through Microsoft hosted activation services, either via the Internet or by telephone.

Get this key from the Volume Licensing Service Center Portal

2.      Office 2013 Generic Volume License Key (GVLK).

The GVLK enables Office 2013 to automatically discover and activate against your KMS host or Active Directory infrastructure.

Get this key from https://technet.microsoft.com/en-us/library/dn385360(v=office.15).aspx

3.      KMS Host Key

A KMS Host Key is used to activate the KMS host with a Microsoft activation server. Get this key from the Volume Licensing Service Center Portal.

KMS in a Non-Domain environment.

This works, but needs additional effort. After considerable trolling on the internet I have not found this documented anywhere so here it is:

1. Clients might not be able to resolve the FQDN of the KMS server.

   Workaround: Ensure the DNS server & DNS suffix is configured on the workstation.

    

2. KMS server does not have permissions to query the workstation for a report.

   Workaround: Ensure the workstation has an admin account with a known password which the KMS server can use for querying.

    

3. Local firewall on the workstation blocks the KMS server query

   Workaround: Enable firewall exception for WMI. (Guidance available on TechNet)

    

4. Grossly mismatched time between server & client might result in authentication failures between the KMS server & the workstation.

   Command to Sync the time on the Client with the time on the KMS server.

   net time \\<kmsserver> /set /y

    

Additional Learnings which I have not found documented.

1. KMS binaries can be downloaded from the Volume Licensing Service Center Portal as an .iso image or from the public Microsoft download center. I used the one from the Volume Licensing Service Center Portal.

   Yet to figure out the difference between the two.

2. Volume Activation Management Tool (VAMT) is purely an optional tool & not needed for KMS functionality. However I would recommend this to be installed.

   In case it does not work properly make sure you upgrade to the latest version whatever the prerequisites.

3. The Help section has a laundry list of commands. The only ones I used were on the client side.

   To Force activation:

   cscript "C:\Program Files\Microsoft Office\Office15\ospp.vbs" /act

    

   To Display the failure history for MAK/retail activation:

   cscript "C:\Program Files\Microsoft Office\Office15\ospp.vbs" /dhistorykms

    

   Note: ospp.vbs is installed as part of the default office 2013 setup.

    

4. VAMT provides a point-in-time view of the computers and products that it manages. It cannot provide an ongoing view of your environment. You should refresh the status from time to time. You can easily get an update license status.   Documented & Reproduced from Here

5. I have not found any way to query the KMS server to know which and how many clients it has activated. The current method of reporting is via the VAMT which connects to the client for a report. If the client is unavailable on the network it will not be reported on.

    

6. Useful Links

   Download: Microsoft Office 2013 Volume License Pack

   https://www.microsoft.com/en-us/download/details.aspx?id=35584

    

   Volume Licensing Service Center Portal

   https://www.microsoft.com/Licensing/servicecenter/default.aspx

    

   Understanding KMS

   https://technet.microsoft.com/en-us/library/ff793434.aspx

    

   KMS activation of Office 2013

   https://technet.microsoft.com/en-us/library/ee624357(v=office.15).aspx

    

   Manage Product Keys Using Volume Activation Management Tool 2.0

   https://technet.microsoft.com/en-in/library/ff686877.aspx

I have been using azure for hosting my virtual machines for several months. I will not list the advantages it gives me in this blob, but since i did not find any blog listing out the steps for an ITpro to simply follow, i am putting the steps i personally follow in a multi-part series.

I am aware that there are enhancements & added features to the PowerShell commands since the time i put together these steps. I plan to cover them at a later stage possibly as a version 2.0

###########################################################################

# Prepare the Workstation for connecting to the azure subscription #

###########################################################################

# Download & install the Windows Azure PowerShell Cmdlets from https://go.microsoft.com/?linkid=9811175&clcid=0x409

# Import the module with the below command:

Import-Module 'C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\Azure.psd1'

# Download the Publish setting file from https://windows.azure.com/download/publishprofile.aspx?wa=wsignin1.0

# This file contains your secure credentials and additional information about your subscriptions for use in your development environment.

# Security Note: This file contains an encoded management certificate that will serve as your credentials to administer all aspects of your subscriptions and related services.

# Store this file in a secure location, or delete it after you use it.

# Import the Publish File using the below command:

Import-AzurePublishSettingsFile 'C:\azure\xxx.publishsettings'

Migrating groups is something I've seen customers assume are not important however when the groups are actually moved, customers experience the pain point some of which could have been mitigated.

1. Detect & fix any corruption in the groups attributes ( if any ).

Common corruption we see is invalid characters in critical attributes like alias & display name. (space, period, special characters, etc.)

There are several ways to detect this corruption. The most simple & crude way would be to do a Get-Group to list all the mailboxes. Any group with invalid attributes would show up in yellow. Besides this you can also use the Office 365 readiness tool to report on invalid attributes ( highly recommended ).

The only reliable fix to detected corruption would be to manually correct the attributes either from ADUC or from ADSI Edit or a similar tool.

Note the difference between Detect & fix above.

I’ve seen customer attempt to fix this corruption via a script to disastrous effect. ( what logic do you use ? )

Tip: If any attributes were changed & you are using Exchange 2003, you should update the RUS & also replicate across the domain controllers.

2. Execute ADMT to copy groups along with the SID.

when executing ADMT, Fix the group membership in the new forest. This could be in one pass or multiple passes depending on your requirements.

A point of significance here is that ADMT does NOT copy all Exchange attributes from the source to target forest.

3. Convert Groups to Universal.

Exchange 2010 requires a local Global Catalog server in the Active Directory site where Exchange resides to query for group expansion. A Global catalog can expand domain local, global, and universal groups. However, domain local groups (and sometimes global groups) can only be expanded within the domain. Hence the GC will be unable to expand a domain local group in a subdomain.

Thus Exchange Server 2007 & 2010 force you to create all new distribution groups as universal distribution groups even if you have a single domain in the forest.

To convert groups to universal using PowerShell run this command:

Get-Group | where { ($_.RecipientTypeDetails -eq "NonUniversalGroup" -or  $_.RecipientType -eq "MailNonUniversalGroup") -and ($_.GroupType -notlike "*DomainLocal*")} |Set-Group –Universal

Iterate by running this command till all groups are converted to universal.

Tip: There are other methods to accomplish this, e.g. with the dsmod command, however the method listed above is what I chose & it works like a charm.

4. Mail enable the groups with source Primary, Secondary (if any) SMTP & legacyExchangeDN.

Given that prepare-moverequest.ps1 cannot be used to prepare groups we need to use another tool for copying the SMTP addresses ( note the plural ) from the source to target forest (both Primary & secondary addresses) along with the LegacyExchangeDN stamped as a x.500 address, reasons for which have been explained in earlier posts.

The tool in question is one which was released for migrating an Exchange 2010 sp1 hosted tenant (/hosting mode ) to another forest which is running Exchange 2010 sp2 ( Non-Hosting mode )

The entire archive of scripts & documentation can can be downloaded from https://blogs.technet.com/b/exchange/archive/2012/02/03/released-migrating-from-exchange-server-2010-in-hosting-mode-to-exchange-server-2010-sp2-whitepaper.aspx

Once un-compressed, we need to run two scripts. One to Create an .xml file with the group details & the second to import the same .xml into the target Forest which will restore the group attributes.

• CreateADMTGroupList.ps1 to Create an .xml file of the group details.

• Copy this xml file to the target forest & import it using the next command.

• RestoreGroupAttributes.ps1 to restore the group attributes to the groups which would have already been copied to the target forest using ADMT.

5. Export list of groups having “exception to e-mail address policy” in source forest & Set the same “policy exception” for the groups copied into the target forest.

 Since hosting environments have the "Automatically update e-mail addresses based on e-mail address policy" unchecked, One un-needed thing the above script does it set an the "Automatically update e-mail addresses based on e-mail address policy" to be unchecked. ( thus the Recipient Policy will not be applied. )

Command to Export ( source forest )

 Get-mailbox | where {$_.policiesexcluded -eq "{26491CFC-9E50-4857-861B-0CB8DF22B5D7}"}

Command to Import ( target forest )

set-mailbox -emailaddresspolicyenabled $false

6. Export List the groups hidden in the source forest & hide the same in the target forest.

for whatever reason they may have been hidden in the source forest, the same would have to be set in the target forest.

Command to Export ( source forest )

Get-mailbox | where {$_.HiddenFromAddressListsEnabled -eq "true"}

Command to Import ( target forest )

Set-mailbox -HiddenFromAddressListsEnabled $true

7. Identify which groups have another group as manager & fix managed-by issue

In Exchange 2010, Unlike earlier versions, distribution groups & mailboxes cannot be managed by groups - only individual users. So it's possible that prior to migration, some groups were used to manage the distribution group.  Now, members of these groups cannot modify the group.

To resolve this, a script Set-DistributionGroupOwners.ps1 can be used. This script replaces a distribution group or security group, which is specified in the “ManagedBy” attribute of a distribution group, with members of the group.

 The script ( Set-DistributionGroupOwners.ps1 ) can be downloaded from here : https://gallery.technet.microsoft.com/scriptcenter/756b02bd-fb8c-4071-b7b3-3e9022831678

additional details can be found here : https://blogs.technet.com/b/exchange/archive/2011/05/04/how-to-manage-groups-with-groups-in-exchange-2010.aspx

8. Enabling users to manage distribution groups but not create or remove them.

The script ( Manage-GroupManagementRole.ps1 ) can be downloaded from here :

additional details can be found here : https://blogs.technet.com/b/exchange/archive/2009/11/18/how-to-manage-groups-that-i-already-own-in-exchange-2010.aspx

9. Upgrade distribution group version.

Distribution groups ( AD objects ) have a version which determine which features are enabled. for example, if the version is E2003, features which are available in later version like E2010 remain greyed out. (e.g. DL moderation ).

In order to get all the features of Exchange 2010, we need to upgrade the version with the below commands.

Command to Upgrade the groups:

Get-DistributionGroup | Set-DistributionGroup -ForceUpgrade

Command to Report the version:

Get-DistributionGroup | ft Name,Exchangeversion

10. Upgrading the E-mail Address Policy

If the email address policy is not upgraded, we will not be able to open the object in EMC

The below command will report which of the e-mail address policies ( aka Recipient Policies ) are legacy.

Get-EmailAddressPolicy | where { $_.RecipientFilterType -eq "Legacy" } | Format-List Name,RecipientFilter*,ExchangeVersion

The below command will upgrade them.

Get-EmailAddressPolicy | where {$_.RecipientFilterType –eq “Legacy”} | Set-EmailAddressPolicy –IncludedRecipients AllRecipients

Note 1 : If you have complex email addressing policies please test before executing the above command.

Note 2 : Mailbox Manager policies are no longer available in 2010 & thus have to be removed.

11. QBDG

Query Based Distribution Groups are best re-created from scratch as the actual query parameters could have changed significantly.

Thanks to an internal communiqué, I recently came across a Readability test of word documents. Surely made for some interesting reading.

To Enable it, you need to enable readability statistics from the options.

Once done, on completing a spell check you will see the following:

The higher the score, the easier it is to understand the document. There are several sources on the internet which explain how to interpret the score.

Further reading can be found here.

https://office.microsoft.com/en-in/word-help/test-your-document-s-readability-HP010148506.aspx#BM2

I Often get questions around how best to install Exchange updates or service packs. This Blog Post attempts to answer that Question.

To start with, I recommend having a Patch management Policy. A Good Patch management policy document should have the following listed:

1. How often should the updates / service pack be installed. ( e.g. Service Pack - once every quarter / critical updates - ASAP)

2. Applications which would possibly have a dependency on the Patch / Service pack. ( BB, Backup, antivirus , archiving, other 3^rd party products ).

These 3^rd party products should be tested for any dependencies on the Update / Service pack.

3. Sequence of server roles to install the Patches on.

Internet facing servers / sites should patched first

Non-internet facing should be after all internet facing sites are updated.

4. AV should be disabled for the time of installation.

5. StartDagServerMaintenance.ps1 before install & StopDagServerMaintenance.ps1 after success to disable replication & re-enable it after SP installation is complete

Additional Reading : https://technet.microsoft.com/en-us/library/bb629560.aspx

6. The Servers must be re-started if the installation of an update / Service pack prompts for a restart.

7. Tests which need to performed to validate services are up & running as expected.

8. Tests which need to be performed to validate the Updates / Service Pack is installed correctly.

*Features

~95.5% reduction in IOPS

Exchange 2013 is capable of being deployed in a multi-site worldwide architecture with a single namespace. ( using multiple technologies )

Auto re-seed to spare disk. ( but needs operational maturity )

*Good to know

CAS is now a protocol proxy only. (2 layers V/S 5 layers)

No longer supports MAPI Clients ( only outlook anywhere )

No MAPI on CAS only RPC-over-HTTP

ECP is now EAC

Notification to admin when certificate is expiring ( EAC )

Maximum DB per server; Enterprise Edition- 50, Standard Edition - 5

one thread per DB

Hard block on 2003 to 2013 migration. (even cross forest )

New server gets into maintenance mode once it is installed

Quota notification e-mail is generated during users login ( V/S every day at midnight in Exchange 2010 )

A .ps1 cannot be executed from a Command prompt. to execute it one needs to use a PowerShell shell. Further if this script calls any exchange cmdlet, it would require to be executed in an Exchange Management Shell.

The following command does all three in one line. i.e. run the script from c:\script\script.ps1 ( which is an exchange script ) from a command prompt.

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -psconsolefile "C:\Program Files\Microsoft\Exchange Server\V14\Bin\exshell.psc1" -file "C:\script\script.ps1"

ADMT 3.2 - 64 Bit Version. ( The first & only version which will install on Windows 2008R2 )

SQL 2008
There are many download options available on the Microsoft website,
* Express Edition & Enterprise Edition
* 32 Bit & 64 Bit
* With & Without Service pack integrated.

Your mileage will vary depending on what version of SQL, Windows & ADMT you use.

For the purpose this migration, I used ADMT 3.2 on a windows 2008 R2, member server with SQL 2008 sp3 Express Edition ( x64 )
This was installed in the target forest.
Password Export Server was installed on a Domain Controller in the source forest.

How to Check the version of SQL ?

Type these commands in a cmd prompt:

sqlcmd -S.
select @@version
go

Additional Reading: Link, Link

3. Moving the Active Directory account using ADMT

ADMT is a great tool for Migrating and Restructuring Active Directory Domains ( user accounts, passwords, groups & group membership, computer accounts & much more.)

However It is very important to note that ADMT DOES NOT touch Exchange attributes.

ADMT can be executed before prepare-move request, after prepare-move request or skipped if we want to use a linked account.

Assuming Prepare-move request was executed first, when executing ADMT we need to merge the account with an existing MEU.

Below are screen grabs of the ADMT wizard. the critical options are highlighted.















 

If ADMT is run prior to the Prepare-MoveRequest.ps1 script is executed, we would need to execute Prepare-MoveRequest.ps1 with the -OverWriteLocalObject Switch.

Further reading Link

4. The Actual Move of Mailboxes.

Having prepared the environment, moving the mailbox should now be a breeze. Given that Moving mailbox is a large topic, so In order to keep this blog concise, I shall jump straight to the command & explain only what is relevant.

1. MRSProxy or NO MRSProxy

   MRSProxy encapsulates all communication between the organizations in HTTPS packets thus making the move seamless.

   Assuming the source forest has Exchange 2010 SP2 or above, enable MRSProxy in the source forest.

   Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSProxyEnabled $true -MRSProxyMaxConnections 50

   Details can be found Here

   In the event that the source forest does NOT have an Exchange 2010 server, we cannot use the MRSProxy. So we skip the above step & use the -remotelegacy in lieu of -remote switch in the move command.

2. Command to Move the Mailbox across the forests ( pull the mailbox from source forest to the target forest )

   First save the credentials in two variables:

   ( target forest )

   $LocalCredentials = Get-Credential

   ( source forest )

   $RemoteCredentials = Get-Credential

   Then execute the command based on whether the source forest has MRSProxy enabled or not.

   • With MRSProxy DISABLED in the source ( even if there is a E2010 server in the source )

   New-MoveRequest

   -Identity johndoe@tailspintoys.com

   -RemoteCredential $RemoteCredentials

   -TargetDeliveryDomain 'tailspintoys.com'

   -RemoteGlobalCatalog dcx01.contoso.com

   -RemoteLegacy

   • With MRSProxy enabled in the source (on a server e2010.contoso.com )

   New-MoveRequest

   -Identity johndoe@tailspintoys.com

   -RemoteCredential $RemoteCredentials

   -TargetDeliveryDomain 'tailspintoys.com'

   -RemoteGlobalCatalog dcx01.contoso.com

   -Remote

   -RemoteHostName E2010.contoso.com

   Note: -RemoteHostName is the E2010 servers where we have enabled the MRSProxy

   When the above commands are executed, it will result in the source mailbox turning into a Mail User ( MEU) & the Target Mail User (MEU) into a user mailbox.

   Source forest:

   User Mailbox> Mail User ( MEU )

   Target forest:

   Mail User (MEU) > User Mailbox

   Before Move:

   

   Move Command:

After Move:

1. 

   Note: Issues to be aware of when moving across forests

   1. Outlook nickname cache is best cleared ( from the client side )
   1. Update OAB & replicate to the CAS servers. Have the users wait till it downloads or ask them to manually download the OAB.
   1. Depending on how end-users have created their outlook rules, it could break. You might need to re-create the outlook rules.
   1. Shared mailboxes + their users & manager + delegate sets should be moved together. you cannot have a manager in one forest & delegate in a different forest
   2. This Mailbox pull will result in the source mailboxes being hard deleted. Ensure you have a backup in case you need to retrieve the mailbox
   1. "Suspend this move when it is ready to complete" option is not available when moving across forest.

   Additional Reading.

   https://technet.microsoft.com/en-us/library/dd351123.aspx

   https://blogs.technet.com/b/exchange/archive/2010/08/10/3410619.aspx

5. Ensuring Mail flow between source & target during the co-existence phase.

The Method described below would work fine if we have to migrate all the mailboxes from the source forest to the target forest rapidly & in one scheduled activity. This is because both the source & target forest are authoritative for the same SMTP domain.

This drawback ( of having to move all the mailboxes in one scheduled outage ) would be acceptable if the number of mailboxes is small or the actual move would happen in a short span of time. However this is not a common scenario as most migrations would take several hours if not days or weeks.

In the event that the move of mailbox takes several hours, days or weeks, we would need to have e-mail flowing between the source forest, ( mailboxes which are going to be migrated ) & the target forest ( mailboxes which have already been migrated ) Thus a migrated user can send an e-mail to a user who is yet to be migrated & vice-versa.

The additional steps to achieve this would involve:

 

1. Add a new accepted domain e.g. @tailspintoys.local in the target forest and also add this domain as a secondary SMTP address to the target forest objects.

Thus we have an additional secondary SMTP e-mail address of johndoe@tailspintoys.local

set-emailaddresspolicy -id "Default Policy" -enabledemailaddresstemplates SMTP:@tailspintoys.com,smtp:@tailspintoys.local

update-emailaddresspolicy -id "Default Policy"

 

2. Modify the move command used earlier. Change the TargetDeliveryDomain to tailspintoys.local

e.g. New-MoveRequest -Identity johndoe@tailspintoys.com -RemoteCredential $RemoteCredentials -TargetDeliveryDomain 'tailspintoys.local' -RemoteGlobalCatalog dcx01.contoso.com -RemoteLegacy

Thus the Target address on the MEU in the source forest after the mailbox is moved will be johndoe@fabrikam.local besides the expected proxy addresses.

Once Executed, we will now have the MEU in the source having a target address of tailspintoys.local

 

3. Create appropriate connectors for mail flow.

In order to have e-mail flowing between the two forests we would need to configure connectors in both the forests. This procedure could vary depending on how the existing mail flow is configured.

Here are the PowerShell commands used in my lab:

source_to_target mail flow

Source send connector

new-SendConnector

-Name 'source_to_target'

-Usage 'Internet'

-AddressSpaces 'SMTP:*.tailspintoys.local;1'

-IsScopedConnector $false

-DNSRoutingEnabled $false

-SmartHosts 'ex01.fabrikam.com'

-SmartHostAuthMechanism 'None'

-UseExternalDNSServersEnabled $false

-SourceTransportServers 'ex01.contoso.com'

Target receive connector

new-ReceiveConnector

-Name 'source_to_target'

-Usage 'Internet'

-Server 'EX01.fabrikam.com'

-Bindings '0.0.0.0:25'

-RemoteIPRanges '10.10.10.103'

target_to_source_and_internet mailflow

target send connector

new-SendConnector

-Name 'target_to_source_and_internet'

-Usage 'Internet'

-AddressSpaces 'SMTP:*;1'

-IsScopedConnector $false

-DNSRoutingEnabled $false

-SmartHosts 'ex01.contoso.com'

-SmartHostAuthMechanism 'None'

-UseExternalDNSServersEnabled $false

-SourceTransportServers 'EX01.fabrikam.com'

source receive connector

new-ReceiveConnector

-Name 'target_to_source_and_internet'

-Usage 'Custom'

-Server 'Ex01.contoso.com'

-Bindings '0.0.0.0:25'

-RemoteIPRanges '10.10.10.11'

-AuthMechanism 'Tls, ExternalAuthoritative'

-PermissionGroups 'AnonymousUsers, ExchangeServers'

Note1: usage = internet as this would not require authentication.

Note2: RemoteIPRanges is the IP address of the server used in the send connector matching this receive connector. This will result in only the identified server being able to send e-mail over this receive connector.

Note3: For this example I have chosen to create a separate send & receive connector in both the forests. However you could also achieve this by modifying the existing receive connectors instead of creating new receive connectors.

6. Additional configuration needed.

• AutoDiscovery for outlook clients ( also used by free-busy )  Reference link
• Free-busy / Availability information.
• Redirecting OWA across forests
• Linked mailboxes
• Shared / Resource mailboxes

I hope to cover these in future blogs, time permitting.

Additional Reading Link1 Link2 Link3

Thank you for reading this far & I hope this blog was useful for your cross-forest migration.

Next Blog: How Groups can be migrated across forests & what kind of issues can crop up.