Second Challenge: Move Mailbox Error:

As explained in Part II, we will use ADMT first to migrate SID History, Password and other AD attributes then we will use Prepare-MoveRequest, the idea of these steps is to get healthy Mail Enabled User (MEU) that will be used later to move the mailbox from the source forest to the target forest, after finishing Part II now we have the healthy MEU and we can check the LDAP properties for the mandatory attributes required for the move to succeed.

The following snapshot shows the LDAP attributes:

Now this is the time to run New-MoveRequest to migrate the mailbox from the source forest to the target forest.

The following snapshot shows the result of running New-MoveRequest:

The error is: Cannot find a recipient that has mailbox GUID

The error is clearly saying that there is no MEU with the mandatory attribute msexchmailboxguid, however when we check the MEU LDAP property:

The mailbox GUID is there (of course it’s there because Prepare-MoveRequest migrated this attribute, check Part II), so what’s the problem?!

We have MEU with the required msexchmailboxguid and each time we try to migrate the mailbox we will get the same error: Cannot find a recipient that has the mailbox GUID.

The problem here that when the remote forest implies a child name relationship, Exchange 2010 will think that this is a child domain and then the strange error will be returned. In our case the source forest name is egypt.tailspin.com and the target forest name is tailspin.com so Exchange will think that the target is child domain from the source forest and it will fail.

So what’s the solution?

We have two painful options:

1. Export all mailboxes as PST files from the source forest and then import it in the target forest: this option is based on big bang approach where there is no co-existence. This option might be considered in small companies where we can disconnect the source forest, export the PSTs and import it to the target forest in reasonable downtime.

2. Co-Existence: when co-existence is required in enterprise companies with thousands of users the only option will be creating Intermediate Forest.

Intermediate Forest:

As you might guess this will be our option as co-existence is required, in this option we will do the migration on two steps.

First we will need to create a new Active Directory Forest with a different name in our scenario we will use nwtraders.com. This forest will contain Exchange 2010 server we can use single server with HUB/CAS/MBX installed on the same server, as this forest will be intermediate and will not serve any users you may decide that high availability is not required.

Now the migration will be done on two steps as following:

1. Move the mailbox of the user (batch of users) from the source forest egypt.tailspin.com to the intermediate forest nwtraders.com.

2. Move the mailbox of the user (batch of users) from the intermediate forest nwtraders.com to the target forest tailspin.com.

After implementing the intermediate forest it’s very important to complete the following tasks before starting the migration:

1. Apply SSL certificate on the intermediate forest that can is trusted and can be validated from the target forest. If Exchange 2010 server in the target forest can’t validate the certificate moving mailbox will fail.

2. Enable the MRS Proxy service: this service responsible of moving the mailboxes from/to Exchange 2010, as the intermediate Exchange server will be 2010 then moving mailboxes will not work without enabling the MRS Proxy service.

The following section contains the detailed steps required to prepare the intermediate forest:

1. Install SSL Certificate

This certificate must be trusted and validated from the CAS servers in the target forest. The certificate could be generated from internal Certification Authority trusted by the CAS servers in Corp forest.

The steps to request to install the certificate as follow (on Intermediate Forest Exchange Server):

a. Request certificate:

I. Open Exchange Management Shell:

II. $data = New-ExchangeCertificate -GenerateRequest –domainname mail.nwtraders.com,autodiscover.nwtraders.com,servername.nwtraders.com -FriendlyName Int-CAS

II. Set-Content -path "C:\CertRequest.req" -Value $Data

b. Import the Certificate:

I. Import-ExchangeCertificate -PrivateKeyExportable:$true -FileData ([Byte[]]$(Get-Content -Path C:\cert.cer -Encoding Byte -ReadCount 0)) | Enable-ExchangeCertificate -Services IIS

2. Enable MRSProxy Service

This step should be completed before moving the mailboxes from the Intermediate forest to the target forest.

a. On the Client Access server in the Intermediate Forest (nwtraders.com), open the following file with a text editor such as Notepad:

C:\program files\microsoft\Exchange\V14\ClientAccess\ExchWeb\EWS\web.config

b. Locate the following section in the Web.config file:

<!-- Mailbox Replication Proxy Service configuration -->

<MRSProxyConfiguration
IsEnabled="false"
MaxMRSConnections="100"
DataImportTimeout="00:01:00" />

c. Change the value of IsEnabled to "true".

d. Save and close the Web.config file.

In this part we addressed the second challenge and now we are ready to start the migration, in the next part we will start by configuring co-existence between the three forests.

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part I

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part II

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part III

Starting from this part we will talk about migration challenges and the best way to address these challenges.

A quick reminder of the current environment:

First Challenge: ADMT First Then Prepare-MoveRequest.Ps1:

As explained in Part I, we need to migrate user accounts and mailboxes from the source forest to the target forest. However in the target forest (tailspin.com) we already have user accounts created manually for users in the source forest (egypt.tailspin.com), so each user in egypt.tailspin.com has two user accounts:

• Primary Account: AD User in the Egypt forest used for Windows logon, email and everything.
• Secondary Account: AD user account created in Tailspin.com forest used for other applications hosted in tailspin, this user used to grant permissions and create profiles on Terminal Service servers.

So the main target is we need to use the existing users in the target forest (tailspin.com), the consequences of this decision as follow:

1. We can’t use the script first; the script in this scenario will create a new disabled Mail Enabled User (MEU), and will ignore the existing user account.
2. We will have to run ADMT first to synchronize the password, migrate SID history, and other AD attributes from the source forest to the target forest.
3. We need to provide prepare-moverequest.ps1 with attribute that links the user in the target forest with the user in the source forest, so when the script runs it will merge all the properties from the source account to the target account and will not create a new user.

Before going to the detailed steps, let’s see the history and the relation between ADMT and Prepare-MoveRequest.Ps1:

• ADMT and Exchange Attributes: By default ADMT doesn’t migrate Exchange attributes including “mail”, “proxyAddresses”, anything started by msexch. The reason behind that because when ADMT transfers Exchange attributes (e.g. homeMDB, homeMTA, showInAddressBook, msExch*) that will make the target user looks like a legacy mailbox in the target domain. This leaves the target account in an invalid state (e.g. homeMDB still points to the old forest) which is unexpected for the PrepareMoveRequest.ps1 script. To prevent this, Exchange attributes are excluded from ADMT.
• In Exchange RTM, running ADMT first and then running the PrepareMoveRequest script: When a user is created via ADMT, the PrepareMoveRequest script doesn't work since there are no proxyAddresses for the script to match the source forest user with the target forest user (the script is looking for some attributes in the target account and try to match it with the source account).

The recommended approach was to copy at least 1 proxy address using ADMT. Even after doing that and using the -UseLocalObject parameter, the script will only copy the 3 mandatory parameters (msExchMailboxGUID, msExchArchiveGUID, msExchArchiveName). This is not very useful as the other mandatory attributes are not copied.

• In SP1, a new switch has been added –OverwriteLocalObject which mainly designed when running ADMT first scenario. ADMT can copy the SIDhistory, password, and proxyAddresses, and the PrepareMoveRequest script can attach the source account with the target account and sync the other email attributes. In this case, it will copy attributes from source to target, so it's the opposite of UseLocalObject.

PrepareMoverRequest.ps1:

The PrepareMoveRequest.ps1 script can identify and match existing accounts in the target forest based on their SMTP address (proxyAddresses attribute).

The script will only use the existing target accounts if all the following are true:

• The target account has a value in proxyAddresses which matches one of the proxyAddresses of the source account.
• The target account is a mail enabled user (healthy MEU that can be retrieves with Get-MailUser command, which means it must have mail attributes like 'mail', 'ExternalEmailAddress', etc).
• You need to specify the -UseLocalObject parameter in the script. (and –OverwriteLocalObject)

If all these are true, the script will copy further attributes needed (especially msExchMailboxGUID) to the target account so that the move request can process the accounts.

If one of the above items is missing, the script will duplicate by creating a new disabled Mail Enabled User (MEU), and no error will be returned, using the script in verbose mode will let you see the details.

Based on that the steps to solve this challenge should be:

1. Select the user or patch of users to be migrated.

2. Delete any Mail Contact for the users in the target forest.

3. Use ADMT to migrate the user account (merge) from source forest to target forest, this is required to get SID History and sync the password.

Once ADMT migration is completed we should have normal user accounts with SIDHistory as the following snapshot:

4. Make the user (or patch of users) Mail Enabled User (MEU) (by running Enable-MailUser), setting ExternalEmailAddress matches the same email address of the user in the source forest (this will be the anchor to associate the user in the target forest with the user in the source forest).

The following snapshot shows how to do it for bulk users using (Import-CSV)

We have a very simple csv file that contains two fields as the following snapshot:

Now we should have a healthy MEU ready for Prepare-MoveRequest, the following snapshot shows the LDAP properties of this user account:

Check the proxyAddresses, mail, and mailNickname.

5. Use Prepare-MoveRequest.Ps1 with –uselocalobject and –overwritelocalobject, so the script will use the existing user account and overwrite the attributes in the target account by the attributes in the source account and most importantly migrate all the required attributes, so the MEU is ready to move the mailbox.

Again we can do it for bulk users by using (Import-CSV), the following snapshot shows the command in verbose mode:

Check the first two lines, local account has been found and the anchor (proxyAddresses) has been used to identify it, then Merge will be done, last line indicates that the process is successfully completed.

Now we have MEU ready to move the mailbox.

In this part we solved the first challenge, in the next part we will continue with the second challenge before moving to the technical steps of the migration.

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part I

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part II

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part III

In this scenario we will use tailspin.com domain. The normal upgrade scenario is to implement and configure Exchange 2010 CAS with the wildcard certificate, then import the wildcard certificate on Exchange 2007 CAS, and the following will be applied:

1. mail.tailspin.com will point to the CAS 2010 server

2. legacy.tailspin.com will point to CAS 2007 server.

3. CAS2007 URLs will be changed to legacy.tailspin.com (OWA, ActiveSync, OAB, EWS), including Outlook Anywhere endpoint.

4. CAS 2010 URLs will be configured with mail.tailspin.com.

The migration process details will not be covered in this blog, so let’s see Outlook problems directly:

1. Outlook 2010 on Windows 7: everything will work perfectly fine with no problems.

2. Outlook 2007 before SP2: Out Of Office will not work internally using RPC until you apply Service Pack 3 and latest updates.

3. Outlook 2007 SP2 with Windows 7: will work internal by RPC and from Internet by Outlook Anywhere.

4. Outlook 2007 with Windows XP: Outlook RPC internally will work fine. Outlook Anywhere will keep asking about user name and password repeatedly and will not work.

 

The problem here that Outlook 2007 will check the value of msstd in the configuration of Outlook Anywhere:

And then Outlook 2007 will compare the msstd value with the common name value in the certificate, as we are using wildcard certificate this value will be *.tailspin.com. and as the value is not the same it will keep asking for credential and Autodiscover will not work.

The solution as mentioned in this article: http://technet.microsoft.com/en-us/library/cc535023(EXCHG.80).aspx is to use set-outlookprovider command as the following:

Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:*.tailspin.com

This command will simply change the value of msstd populated by Autodiscover to *.tailspin.com, so Windows XP will find the same value as the common name value in the wildcard certificate.

This blog will focus on the client side behavior once applying this command, as explained before:

1. Anything on Windows 7 will work fine (Outlook 2007 and Outlook 2010).

2. Outlook 2007 with sP3 and Windows XP: Outlook RPC will work fine internally, autodiscover will update the msstd value to *.tailspin.com.

3. Outlook 2007 with SP3 and Windows XP: Outlook anywhere was as the above snapshot, and will keep prompting for user name and password, but because now the msstd value is the same as the common name, Autodiscover will work and will fix the profile but in order to have the new settings you will need to restart Outlook.

The following snapshot from Outlook using outlook anywhere after putting the user name and password first time, then click cancel after that:

In the above snapshot note that Autodisover changed msstd to *.tailspin.com, also note that Outlook is still need password.

Note also that Autodiscover didn’t update the Outlook Anywhere end point to legacy.tailspin.com (which is the normal behavior of Outlook), Outlook Anywhere will work fine because E2010 CAS will proxy to Exchange 2007.

If you want to change the Outlook Anywhere endpoint then you will need to repair the profile, so you will have the right endpoint. In our scenario because we don’t want the users to do any changes and because we will move the mailboxes and at the end all users will mail not legacy we just informed the users to open Outlook, put the username and password, then close Outlook and Open it again.

Now close Outlook and open it again, you will be asked for username and password (as normal basic authentication in Outlook Anywhere) and everything will work perfectly:

Note that now Outlook is connected through Outlook Anywhere, and OOF is working fine:

Last comment on this, if the client connected through RPC (internally) after adding set-outlookprovider command:

Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:*.tailspin.com

Outlook will get the changes through Autodiscover and will change the msstd value to *.tailsping.com, and next time when the client is accessing from the Internet by OA everything will work fine.

So the expected behavior will be:

1. Start Outlook from Internet (OA) after the changes:

a. Users will be prompted for username and password (Windows XP & Outlook 2007).

b. Autodiscover will update the msstd value with *.tailspin.com.

c. Restart Outlook to the new settings to take effect.

2. Outlook will be started internally (RPC) after the changes:

a. Outlook will get the new value of msstd through Autodiscover.

b. No user name and password, everything will work fine on RPC.

c. When try OA after that everything will work because the msstd value is updated.

Having say so it will worth to note that Autodiscover works in the following conditions:

• Every time that the application starts
• At intervals on a background thread (every 60 minutes)
• Any time that the client's connection to an Exchange server fails

Which means if Outlook is already running during the changes, Autodiscover will modify the value based on the background thread (maximum 60 minutes after changes).

During Implementation of Exchange 2010 the old transport rules will be copied from Exchange 2007 to Exchange 2010 new location (the format and location of the transport rules are changed in 2010).

However you may have the disclaimer is working fine from users in Exchange 2007 (because they are using HUB 2007) and not working for the users in Exchange 2010.

The problem here that disclaimer in condition “Outside the organization” will not work when not having out of the office and legacy messages allowed to external, the solution is very simple as the following snapshot:

Restart the transport service on all hub servers you have and the disclaimer will be applied.

Error when moving mailbox: Cannot find a recipient that has mailbox GUID.

The following snapshot shows the result of running New-MoveRequest:

The error is: Cannot find a recipient that has mailbox GUID

Problem:

The error is clearly saying that there is no Mail Enabled User (MEU) with the mandatory attribute msexchmailboxguid, however when we check the MEU LDAP property:

The problem here that when the remote forest implies a child name relationship, Exchange 2010 will think that this is a child domain and then the strange error will be returned. In our case the source forest name is egypt.tailspin.com and the target forest name is tailspin.com so Exchange will think that the target is child domain from the source forest and it will fail.

The following KB2598985 (which just released from 3 days) is talking about this scenario. http://support.microsoft.com/kb/2598985

Solution:

Before the release of Exchange 2010 SP2 Rollup Update 1 the solution one of the following painful options:

1. Export all mailboxes as PST files from the source forest and then import it in the target forest: this option is based on big bang approach where there is no co-existence. This option might be considered in small companies where we can disconnect the source forest, export the PSTs and import it to the target forest in reasonable downtime.
2. Co-Existence: when co-existence is required in enterprise companies with thousands of users the only option will be creating Intermediate Forest: Create new forest with different name (ex: intermediate.local), move mailboxes from source forest to the intermediate forest, then move the mailboxes again from the intermediate forest to the target forest, this option explained in details in my earlier blog post: Exchange 2010 Cross-Forest Migration Step by Step Guide – Part III (http://blogs.technet.com/b/meamcs/archive/2011/10/25/exchange-2010-cross-forest-migration-step-by-step-guide-part-iii.aspx)

Note: This problem has been solved with Exchange 2010 SP2 RU1 which you can get from the following URL: http://www.microsoft.com/download/en/details.aspx?id=28809 .

So if you need more information about PST Capture Tool, check the following URLs:

1. Download the PST Capture Tool: http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=28767
2. PST Capture Tool Documentation: http://technet.microsoft.com/en-us/library/hh781036

As a quick review on how to configure PST Capture Tool with Office 365, you will need first to configure:

1. PST Search: and select the computers where you will search for PSTs: http://technet.microsoft.com/en-us/library/hh781034
2. Create Import List: contains the list of PSTs to be imported to the cloud.
3. Then configure the tool settings for Office 365 as the following snapshot:

As the above snapshot, you will need to enter:

1. User Name: this account should be Global Administrator on your tenant. (In this article the tenant will be domain.onmicrosoft.com).

2. Select: Grant delegate access to this mailbox.

3. Enter the server name: you can get the server name for your account from OWA:

          a. Click options, then see all options

          b. Under “My Accounts” click on “Settings for POP, IMAP, and SMTP access... “

4. Select: The above is an Office 365 Server.

Then click check to check password and connectivity. And you will receive the following error:

Cannot connect to user pst@domain.onmicrosoft.com inbox on server servername. Error is request failed. The remote server returned an error: (401) Unauthorized.

The following snapshot shows the error:

Very clear!! , this error will happen if you didn’t logon with this account on Outlook before. So the simple solution will be:

1. As the tool prerequisites, you should have Outlook installed on the same server.
2. Configure Outlook profile for the user you are using in the tool (pst@domain.onmicrosoft.com).
3. Open Outlook and logon to the account.

Go back to the PST Capture Tools, click Check and voila:

As you can see in the above snapshot you are successfully connected to Exchange Online. Now you can continue the steps to upload the PST to the cloud.

Challenges of Migration from GroupWise to Exchange 2010: Co-Existence

In this article I will talk about one of the most annoying problems that may affect the migration which is meeting request between Exchange and GroupWise.

Symptoms:

Meeting requests from GroupWise to Exchange working fine. However meeting requests from Exchange to GroupWise delivered as normal email without Accept/Deny buttons.

The following snapshot shows how GroupWise client receive the meeting request from Exchange:

As in the previous snapshot, meeting requests appear as normal email to the recipient.

Solution:

From Exchange Management Console (EMC), open the properties of the mail contact created for GroupWise recipient and for Use MAPI rich text format select “Never”, as the following snapshot

As expected GroupWise will never understand the MAPI format and will treat the meeting request as normal email.

This can be done for bulk users by simply execute the following cmdlet:

Get-MailContact |Set-MailContact -UseMapiRichTextFormat:never

After executing the cmdlet now the meeting request is a meeting request in GroupWise client:

The following steps summarize the migration process from GroupWise to Exchange 2010:

1. Design Exchange 2010.

2. Implement and configure Exchange 2010.

3. Select the migration software (3^rd party).

4. Setup Co-Existence between GroupWise and Exchange.

5. Migrate the users’ mailboxes.

In this article I will concentrate on Step 4. In my environment I will use Quest tools for the migration. Reading most of Quest guidance they covered the implementation of the tool and step 5 only, while the most important step (Step 4) is not covered.

Simply co-existence including mail flow is product configuration and not relevant to the migration software. In this article I will explain how to have mail flow between both systems and also will cover share SMTP namespace.

There are three options to for mail co-existence:

1. Single Namespace: in this scenario we will have one domain to cover both systems. As example tailspin.com domain will be used in both systems, each system will forward the emails to the other if there is no recipient locally as follows:

When users in GroupWise send email to one of Exchange users, GroupWise will not find a mailbox for the recipient locally and will forward the email to Exchange, same from Exchange side.

Problem: while this is easy to configure from Exchange side, I couldn’t find a way to do it from GroupWise side that will not result in loop. To avoid loops we must have one side responsible on sending NDR if it can’t find the user.

2. Different Domains: in this scenario we will have two different domains, one for each system:

a. groupwise.tailspin.com: for GroupWise users. Exchange users  will send to users in GroupWise using this address.

b. exchange.tailspin.com: users in GroupWise will send emails to Exchange users using this address.

3. Hybrid: to mix both approaches as follow:

a. Exchange Side: will use single namespace, Exchange will have mail contacts for all users in GroupWise, when mailbox in Exchange is sending to one of the GroupWise users (contacts in Exchange), Exchange will forward the email to GroupWise server. This will maintain GroupWise as the owner of the domain, which means if the user is not exist in GroupWise, GroupWise will issue Non Delivery Report (NDR).

b. GroupWise Side: for users planned to be  migrated from GroupWise to Exchange, Quest tool will configure forwarding rule that will forward all emails sent to user1@tailspin.com to user1@exchange.tailspin.com which reside on Exchange servers.

I’ve selected option 3 in my environment and the following steps explain the steps of how to configure in both environments:

 

Step 1: Configure Exchange with tailspin.com as shared namespace:

In Exchange we will need to configure the following:

1. Internal Relay Domain: the internal relay simply means that Exchange is not Authoritative (owner) of this domain, which means if the recipient email is not exist on Exchange it may be exist on another system (so no NDR will be generated).

The following article contains more information about the accepted domain: http://technet.microsoft.com/en-us/library/bb124423.aspx

The following snapshot shows how to configure Internal Relay Domain:

2. Create and configure Send Connector:

Create custom send connector with domain tailspin.com, make sure that the source server is the HUB servers (not Edge) and select “Route mail through Smart Host” this is should be the IP of the GroupWise server, if you will use CMG (Quest Co-existence Manage for GroupWise) then the IP should be the CMG’s IP.

3. Make sure that you have mail contact created for all users on GroupWise side, this is a mandatory step for the migration later, and can be done using Quest CMG (Co-existence Manage for GroupWise) Directory Connector or by import users to Active Directory using CSV file.

Step 2: Configure GroupWise Side:

When migrating a user from GroupWise to Exchange, one of the steps when using Quest tool “GroupWise Migration for Exchange” is to forward emails to Exchange account which should be user@exchange.tailspin.com.

So the steps to configure GroupWise as follow:

1. Configure Smart Host: this step will configure GroupWise to send all emails send to particular domain (exchange.tailspin.com) to a specific IP, again if you will use CMG then this is the IP of the CMG server.

This configuration should be done through route.cfg file on the GroupWise server, this file location is domain\qpgate\gwia, create the file if it’s not there.

Open the file in text editor and add the following line:

exchange.tailspin.com xxx.xxx.xxx.xxx

Where the IP is CMG IP or Exchange 2010 HUB. And restart the GWIA service (this is the service responsible of send/receive SMTP, similar to Exchange Transport Service)

2. Enable Flat Forwarding: in GroupWise the forward rule will send the email with from field from the user, example: user1 send email to user2, there is forward rule to forward all emails sent to user2@tailspin.com to user2@exchange.tailspin.com, all emails will go to Exchange side with from field from user2@tailspin.com (very strange to Exchange guys like me :)). To present from field as the real sender of the message we will need to enable flat forwarding.

The following steps show how to do it:

a. Open ConsoleOne > Browse to GWIA > open properties.

b. Select SMTP tab > check to enable flat forwarding. As the following snapshot:

3. When migrating the user’s mailbox using Quest GME (GroupWise Migration for Exchange) you will select GroupWise Administrative functions > select set forwarding from GroupWise to Exchange.

4. Step 3: Testing:

Send emails from Exchange to GroupWise and vice versa.

This article explained the main challenge which is co-existence, in the next articles we will discuss some of the migration problems that may happen during Step 5: The migration.

This is very famous issue when you create many Virtual Machines on Windows Azure, after deleting the VMs the virtual disks (VHD files) are still there.

So far there is no way to remove these VHD files using the GUI interface, so I started to search how can I do it through PowerShell. The challenge of Azure PowerShell is that most of the resources available for developers using Visual Studio, for me any thing starts with Visual Studio is sort of mystery (The nice story that one of my developer friends identify SharePoint Site Collection: is a site contains collections is true story) that should be left to wisdom men (like this friend) who can understand it .

For Infrastructure guys like me, the following are step by step of how to use PowerShell to connect to Azure and then delete the VHDs:

Step 1: Management Certificate:

In simple words we will need a certificate to connect with PowerShell to Azure, this certificate should be 2048 bits at least, self signed certificate is good option for testing and labs.

Creating Self Signed Certificate can be done by many ways, the easiest way is using the normal PowerShell:

1. Open PowerShell (as an Administrator).

2. Type the following cmdlet:

New-SelfSignedCertificate -DnsName azure -CertStoreLocation cert:\LocalMachine\My

This cmdlet will create new self signed certificate and place it in the local machine store, check the following snapshots:

Let’s make sure that the certificate is created:

1. From Run > Type mmc.

2. Click File > Add/Remove Snap-in.

3. Select Certificate and Click Add.

4. Select Computer Account > Finish.

5. Under Personal > Certificate > you should find the new certificate “azure”:

The next step is to upload this certificate with private key (the PFX file) to Windows Azure, in order to do that you will need to export the PFX file (the certificate with the Private Key) first:

1. From the same Snap-in.

2. Right click the certificate > All Tasks > Export.

3. Click Next > Select “Yes Export the Private Key” > Click Next.

4. On Export File Format click next > Then provide the password.

5. Browse to the location where you will save the certificate.

From Azure Management Portal create a new Cloud Service to use it with the certificate:

After having the PFX file we will need to upload it to Windows Azure:

1. Log into the Management Portal.

2. In the navigation pane, click Cloud Services, and then click the service for which you want to add a new certificate.

3. On the ribbon, click Certificates, and then click Upload a Certificate.

4. In the Upload certificate dialog, click Browse For File, go to the directory containing your certificate, and select the .pfx  file to upload.

5. Type the password of the private key for the certificate.

6. Click OK.

Step 2: Install Azure PowerShell

To install Windows Azure PowerShell:

1. Download Windows Azure PowerShell: http://go.microsoft.com/?linkid=9811175&clcid=0x409 
2. Install Windows Azure PowerShell.

Step 3: Connect to Azure:

Before we start using the Windows Azure cmdlets to remove the VHDs or anything else, we will need to configure connectivity between the workstation and Windows Azure. This can be done by downloading the PublishSettings file (this file will setup the PowerShell environment to use Windows Azure) from Windows Azure and importing it. The settings for Windows Azure PowerShell are stored in: <user>\AppData\Roaming\Windows Azure PowerShell.

1. From Windows Azure PowerShell type the following cmdlet:

   Get-AzurePublishSettingsFile

   A browser window opens at https://windows.azure.com/download/publishprofile.aspx, where you can sign in to Windows Azure.

2. Sign in to the Windows Azure Management Portal, and then follow the instructions to download your Windows Azure publishing settings. Use your browser to save the file as a .publishsettings file to your local computer. Note the location of the file.
3. In the Windows Azure PowerShell window, run the following command:

   Import-AzurePublishSettingsFile FileName.publishsettings

Step 4: Remove the VHDs (Finally)

Once we are connected now to Azure, we can manage Azure with PowerShell and do anything we need, if you forgot what was the purpose of this article this is the time you will need to scroll up and read it again

Run the following cmdlet to see all the virtual disks (the VHD file):

Get-Azuredisk

In the above snapshot this is the disk that I want to remove (you will need to make sure that is not connected to any Virtual Machine), then run the following cmdlet:

Remove-AzureDisk <DiskName>

Now you will probably decide to leave the VHDs and not delete them which is easier , I don’t blame you for that. But you will have this article as reference in case one day someone asked you the question: How can I remove the unused VHD file.

for more details about Azure PowerShell: http://msdn.microsoft.com/en-us/library/windowsazure/jj156055.aspx

for more information about Azure Management Certificate: http://msdn.microsoft.com/en-us/library/windowsazure/gg981929.aspx 

Reporting

First question you will get after setting up the tenant and create the users will be: I need list of all users with a specific parameter.

The main cmdlet here is Export-Csv this cmdlet can be used to export the result to the CSV file:

I need list of all licensed users

Get-MsolUser | Where-Object {$_.isLicensed -eq "TRUE"} | Export-Csv d:\licensedUsers.csv

In the above cmdlet:

1. First part we are getting all users.

2. Second part is to filter users with parameter islicensed=true

3. Export the list of users to the CSV file.

Let’s open the result file in notepad:

We have a lot of problems:

1. Arabic is “?????” so the file isn’t useful. The default format is ASCII so we need to make it Unicode.

2. The first line is listing the .Net Object Type.

3. Also there a lot of not needed values like the first column.

So let’ make some modification to the cmdlet:

Get-MsolUser | Where-Object {$_.isLicensed -eq "TRUE"} | Select-Object -property "UserPrincipalName" | Export-Csv -Encoding unicode d:\licensedUsers.csv -NoTypeInformation

In the above cmdlet:

1. The third part is added for the filtered users we select the following properties: UserPrincipalName and Department.

2. In the last part for the exported CSV file we set the encoding to Unicode instead of ASCII (the default value).

3. And to remove the .Net value we have added –NoTypeInformation

And the result as follows:

Now the file can be useful for reporting, so let’s see more examples:

I need List of all users with department “?????”:

Don’t forget that you will need PowerShell ISE for Arabic support (review the previous parts).

Get-MsolUser -Department "?????" -all | Select-Object -Property "*princip*",displayname,department |Export-Csv -Encoding unicode -Path d:\?????.csv -NoTypeInformation

All the attributes can be used in Select-Object so we can decide what will be exported.

Let’s add Exchange to the equation:

I need list of users with department “?????” and with mailbox size for each one:

First we will need to connect to Exchange Online as explained in the previous part (Part IV: Dynamic Distribution Group)

Let’s try the following cmdlet:

Get-MsolUser -Department "?????" -all | ForEach-Object {Get-MailboxStatistics -Identity $_.userprincipalname} | Select-Object -Property displayname,"lastlogo*",totalitemsize,storagelimit* | Export-Csv -Path d:\?????.csv -NoTypeInformation -Encoding unicode

Note the following:

1. –all in the first part to get all users, when you have large number of users.

2. Second part we executed get-mailboxstatistics which will return a lot of information.

3. Third part we will select from the returned result only lastlogon and totatitemsize and storagelimit.

Let’s check the result:

Last thing that of course you can open the CSV file in Excel so you have more control:

1. Open Excel first.

2. Open> browse to the file.

3. Select “Delimited”

4. Under Delimiters > select Comma > then Finish.

Now you can check the CSV file in Excel:

In this part I’ve explained how to export specific list of users with specific attributes.

Previous Parts:

Part I: Arabic Problems

Part II: Users Bulk Creation

Part III: Users Bulk Modification

Part IV: Dynamic Distribution Group

Part V: Reporting