Scripts:ExportO365UserList_v2.0 and Import_UserList_For_Archive_Mailbox

    Today, I manage to complete the bellow script, in order to automate exporting user list from Office 365 and also with a second script to enable mailbox archive for specific users

    Let’s take a closer look and see how it works

    What do you need to know before you begin?

    • Make sure you have already installed Windows Azure AD PowerShell
    • You must check and be sure your server or your computer has access to the internet

    Let’s have a quick look how to execute the script ExportO365UserList_v2.0 and Import_UserList_For_Archive_Mailbox.ps1 on Windows PowerShell and what this script do for us.

    1. Login to your computer with Administrator credentials
    2. Start Windows Azure AD PowerShell “As Administrator”


3. Next step, copy the scripts ExportO365UserList_v2.0 and Import_UserList_For_Archive_Mailbox.ps1 on (C:\) drive


4. Let’s start by running the script from Windows Azure AD PowerShell itself.
In case you get weird error messages when you try to run a script, the reason is only one, security settings built into Windows PowerShell include something called the “execution policy” the execution policy determines how (or if) PowerShell runs scripts. By default, PowerShell’s execution policy is set to Restricted that means that scripts – including those you write yourself – won’t run.
Navigate back to Windows PowerShell and set the Execution policy to unrestricted in order to be able to run the script, in that case, use this command to set your execution policy to RemoteSigned or Unrestricted


    Note: The Set-ExecutionPolicy cmdlet enables you to determine which Windows PowerShell scripts (if any) will be allowed to run on your computer.

    Windows PowerShell has four different execution policies:

    • Restricted – No scripts can be run. Windows PowerShell can be used only in interactive mode.
    • AllSigned – Only scripts signed by a trusted publisher can be run.
    • RemoteSigned – Downloaded scripts must be signed by a trusted publisher before they can be run.
    • Unrestricted – No restrictions; all Windows PowerShell scripts can be run.
    1. The most common (default) way to run a script is by calling it:

    PS C:\> & “C:\Admin\My first Script.ps1”

    If the path does not contain any spaces, then you can omit the quotes and the ‘&’ operator

    PS C:\> C:\Admin\Myscript.ps1

    If the script is in the current directory, you must indicate this using .\ (or ./ will also work)

    PS C:\> .\Myscript.ps1

    In our case scenario we run the script in the current directory “C:\” so, we must indicate this using .\ and we click Enter


5. Type your Global Admin credentials, Username and Password in order to login and the script automatically will export the Office 365 User List on C:\


6. Go to C:\ drive and check the list which is exported there, with the name O365UserList.csv


7. Next step, is to open the exported list with the excel file, on the list we can see all licensed users, SMTP addresses and display name


    Now we will filter this list and we’ll select only the users that we want to enable mailbox archive


8. I will copy on notepad only the SMTP addresses (UserPrincipalName) and paste them on the notepad as follow

    Note: on the top of the file type Identity


    Save the file on C:\ drive as UserListForMailboxArchive.csv

9. Navigate to Windows Azure Active Directory Module for Windows PowerShell and run the Import_UserList_For_Archive_Mailbox.ps1 script


    As we can see Mailbox Archive was enabled for those users


    You can download the scripts from TechNet Gallery, click here 


Office 365 "W15" Hybrid Deployment (Part VI) – Configuring a Microsoft Exchange Online Hybrid Deployment

After having in Part 5 configure part of Microsoft Exchange Server, in Part 6 and final part we will continue with Exchange Server configuration based migrations to Office 365 or more precisely Exchange Online, we ran the Exchange 2010 SP3 hybrid configuration wizard in order to set up the basic Exchange hybrid configuration.

Let’s go.…

Look at Current Hybrid Configuration

Let’s take a look at the stuff that was created behind the scene, when we ran the Hybrid Configuration Wizard (HCW).
Let’s first look at the hybrid configuration object itself. We can do so by launching the Exchange Management Shell (EMS), and run the following command: Get-HybridConfiguration


As you can see above, the settings (such as hybrid Client Access and Hub transport server, on premise smart host and federation domains) you specified when we ran the wizard have been set on the hybrid configuration object. But, this is not the only thing that have been configured. You can also see which features have been enabled (FreeBusy, MoveMailbox, MailTips, MessageTracking, OwaRedirection, OnlineArchive, SecureMail and CentralizedTransport), which are features we wish to enable between the on premise Exchange organization and the Exchange Online organization in Office 365.
In addition, the following has also been performed in the on premise Exchange organization:
A federation trust with the Microsoft Federation Gateway (MFG) has been established for the specified domain:


Creating a federation trust with the MFG is required in order to be able to set up an organizational relationship, which again is required in order to share free/busy information and calendars between the on premise Exchange organization and the Exchange Online organization in Office 365. With this said, it’s important to note that a trust isn’t set up with the MFG, instead the MFG merely acts as a trust broker between the involved Exchange organizations.

“” has been added as an accepted domain:


Adding the “” domain to the “Accepted Domains” list as an authoritative domain is required in order for the on premise Exchange organization to accept inbound e-mail messages destined for a mailbox user located in Exchange Online. When a mailbox is moved from the on premise Exchange organization to Exchange Online, the source mailbox user object is converted to a mail user object, which is configured with an external address of ““. We will look more at this later in this article series.

“” and “onprem.local” has been added as a remote domain:


A remote domain is an SMTP domain that is external to our Exchange organization. When a new remote domain is created, it’s possible to specify the remote domain is used for Exchange Online purposes. With a remote domain, we can configure out of office and message formatting settings. The HCW sets the ideal setting for a hybrid and enables the SMTP domain as the domain used for an Office 365 tenant, which is important in relation to provisioning of new remote mailbox users (users that get a mailbox created directly in Exchange Online).
The default E-Mail Address policy has been updated, so that it stamps a secondary proxy address ( on mailbox user objects:


The SMTP address ““ is added to the default E-mail address policy, so that it can be stamped as an additional proxy address on the mail objects in the organization. As mentioned earlier, when a mailbox is moved to Exchange Online, the source mailbox user object is converted to a mail user object and in order to be able to set ““ as the external e-mail address, it must already be stamped on the object. The HCW also creates a receive connector on each of the hybrid servers. The purpose of this receive connector is to accept inbound mail that comes directly from Exchange Online in Office 365. The receive connector accepts anonymous connections secured using TLS, but only from the IP range used by Office 365.
In addition, the HCW will create a send connector that will route all e-mail messages destined for “” to Exchange Online in Office 365.


And finally, an organizational relationship has been established with the Exchange Online organization in Office 365:


The organization relationship is used to configure what kind of features should be enabled between the on premise Exchange organization and Exchange Online and for availability sharing at what level.
Let’s take a closer look at the organization relationship that has been created. We can do this by running the following command in the Exchange Management Shell (EMS): Get-OrganizationRelationship | fl
By default, free/busy is enabled with limited details. In addition, mailbox moves, delivery reports, MailTips and online archive are enabled. Moreover, a target OWA URL is specified and by default, it will be set to: “”. The target OWA URL is the URL that a user will be non-transparently redirected to (we will look at this later in this article series), when he tries to access his mailbox using the existing OWA namespace (i.e. after his mailbox has been moved to Exchange Online. Lastly, a target autodisocver has been set by the HCW.
This is the endpoint used to reach out to the Exchange Online organization for the configured features, when a request comes from the on premise Exchange organization to the Exchange Online organization.
In Office 365, the following was configured, when we ran the HCW
Just like for the on premise Exchange organization, the domains used for routing between on premise and Exchange Online has been added as “Accepted Domains” in the Exchange Online organization.


Likewise, for remote domains, these have been configured in Exchange Online. An organization relationship has been configured in Exchange Online, so the sharing requests etc. from an Exchange Online mailbox user to an on premise mailbox user is sent to the on premise Exchange organization.


Just like is the case with the on premise Exchange organization, we can get additional information about the configuration of the organization relationship by running the following command: Get-OrganizationRelationship | fl

Update Hybrid Configuration

If you at some point wish to update the hybrid configuration in your environment, you can do so via the HCW or EMS.
If you want to use the HCW, you simply click on the hybrid configuration object in the EMC, and select “Manage Hybrid Configuration” in the context menu.


If you want to use EMS, you first set the required configuration using the Set-HybridConfiguration cmdlet and then you run the Update-HybridConfiguration cmdlet to push the new configuration to Office 365.
Read more about the Set-HybridConfiguration cmdlet here and the Update-HybridConfiguration cmdlet here.

That is we will move an on premise Exchange mailbox to Exchange Online and then we will test the browser and client behavior and see what to expect when a mailbox has been moved from on premise Exchange to Exchange Online. Moreover, we will be provisioning a new mailbox in Exchange Online using the “New Remote Mailbox” wizard and the “New-RemoteMailbox” cmdlet.
Lastly, I explain what to consider when it comes to decommissioning your Exchange on premise servers or just the legacy Exchange servers within your on premise environment.

Moving a Mailbox

Now that we have configured a hybrid deployment, let’s test things out to ensure they work as expected. First, we will move an on premise mailbox to Exchange Online using the “New Remote Move Request” wizard. This can be done by right-clicking on an on premise mailbox and selecting “New Remote Move Request” in the context menu as shown in


On the “Introduction” page, click “Next”.


On the “Connection Configurations” page, make sure “Target forest” is set to “the name you gave the additional Exchange forest”, then enter the FQDN for the Exchange hybrid server that has the Client Access server role installed. Also, enter the credentials for an on premise administrator and click “Next”.


On the “Move Settings” page, click “Browse” and then select the target delivery domain (in this case “”). Since, we’re moving a mailbox to Exchange Online, we cannot select the target database (it will be picked randomly). Click “Next


On the “Configuration Summary” page, click “New” in order to create the remote move request in Exchange Online.


On the “Completion” page, click “Finish


Let’s go and see how to migrate mailbox data by using the Exchange Admin Center in Office 365

1. Sign in to the Office 365 portal (

2. Click Admin, and then click Exchange.

3. Click Migration, click New (+), and then click Onboarding.

4. Select the migration option that you want, and then click Next. Migration options are as follows:

· Remote move

· Staged migration

· Cutover migration

The following screen shot shows the migration options:


In New migration batch window, click New (+)


Select the user/s that you want to move and click add and then ok and Next



In the next window enter on premise account credentials and click Next


After the wizard finish, the mailbox will be moved successful to Office 365


How to Create Public Folder’s in Office 365 W15

The Public Folders pages is a new feature for Exchange Online introduced with Office 365 Preview. It provides an easy and effective way to collect, organize, and share information with other people in your workgroup or organization. It is not designed for Archiving Data or Document sharing and Collaboration.

In Office 365 Preview every public folder must live in a Public Folder mailbox. You will need to create at least one Public Folder mailbox before you can create Public Folders.

To create a Public Folder Mailbox
Navigate to the Exchange Admin Center (EAC)

Click Public Folders > Public Folder Mailboxes > Click (+) New

Enter a Name and click Save

Check the list to ensure the new Public Folder Mailbox is available

To create a Public Folder
Click Public Folders > Public Folders > Click (+) New

Enter a Name and click Save.

Verify that the folder has been created

In the Public Folder window, note that several new options will be available, e.g:

  • General: Public Folder name etc
  • Statistics: Count of Deleted Items etc
  • Limits: Warning Quotas etc
  • General mail properties: Edit Alias, Display Name, add custom attributes
  • Emails Addresses: Add/Edit additional SMTP Addresses for the public folder
  • Member Of: Add the public folder to distribution groups
  • Delivery Options: Configure Send As, Send on behalf, and Forwarding on the public folder
  • Mail Flow Settings: Enable/Edit delivery restrictions on for the public folder mailbox.

To view Public Folders on Outlook 2013, navigate near to Tasks and you’ll see "………" > click on "…….." and choose Folders

Now you can view your Public Folders on Outlook 20013


  • Kiosk plan users are not licensed for public folders
  • You are limited to 50 public folder mailboxes with a maximum size of 1.25 TB.
  • See the Exchange Online Service Description for more

How To: Give Users Send As Permission

Send As permission, also known as SendAs permission, gives a user permission to use another recipient’s e-mail address in the From address. For example, when you give the user Chris Send As permission on the mailbox of a user named Michelle, Chris can send e-mail messages that appear to be sent by Michelle, with no indication to the recipient that anyone other than Michelle sent the message. Or, if your organization uses a Help Desk distribution group, you can give Help Desk staff Send As permission on the Help Desk distribution group. That way, replies to messages sent to the Help Desk group appear to come from the group instead of an individual Help Desk technician.

To give a user Send As permission, you use Windows PowerShell

Before you begin

  • To learn how to install and configure Windows PowerShell and connect to the service, see Use Windows PowerShell in Exchange Online.
  • The Send As permission is different than the Send on Behalf permission. If the user Chris has Send on Behalf permission on Michelle’s mailbox, when Chris sends an e-mail as Michelle, the From address shows Chris on behalf of Michelle. Microsoft Outlook users can configure Send on Behalf permissions on their own mailbox using delegates. Administrators can configure Send on Behalf permissions on any recipient type using the GrantSendOnBehalfTo parameter.
  • Want more information about parameters? See An explanation of parameters.

Give a user Send As permission
Launch Windows PowerShell and perform the following steps:

Import-Module msonline 
$cred = Get-Credential 
Connect-MsolService -cred $cred 
Get-Command –Module msonline

1) Import the module.
2) Create a credential-object stored in the variable $credimp
3) Create a new remote PowerShell connection against the PowerShell endpoint for Office 365
4) List the cmdlets available

A shortcut to the module is also available on the Start-menu (you can skip step 1 if launching this shortcut):

Run the following command:
Add-RecipientPermission <identity> -AccessRights SendAs -Trustee <user>

For example, to give the user named Joanna Vathis Send As permission for the Test mailbox , run the following command:
Add-RecipientPermission  -AccessRights SendAs -Trustee

Add-RecipientPermission "TEST" -AccessRights SendAs -Trustee "Joanna Vathis"
Joanna can now send messages that appear to come directly from the TEST mailbox.
Note  By default, you are asked to confirm the addition of the Send As permission. To skip the confirmation prompt, use -Confirm:$false.

View Send As permissions

Use the Get-RecipientPermission cmdlet to display all the Send As permissions configured in your organization. You can filter the list to show Send As permissions granted to a specific user and to see the Send As permission on a specific recipient.

View Send As permission for a specific user

Run the following command:
Get-RecipientPermission – Trustee <user>
For example, to list the recipients for whom the user named Kim Akers has Send As permission, run the following command:
Get-RecipientPermission -Trustee
Joanna can send messages that appear to come directly from the recipients

View Send As permission on a specific recipient

Run the following command:
Get-RecipientPermission <identity>

For example, to list the users who have Send As permission on the TEST mailbox, run the following command:
Get-RecipientPermission "TEST"
The users listed can send messages that appear to come directly from the TEST mailbox.

View all Send As permissions you’ve configured in your organization

Run the following command:
Get-RecipientPermission | where {($_.Trustee -ne ‘nt authority\self’) -and ($_.Trustee -ne ‘null sid’)}

Note The filter hides the automatic Send As permission that allows a user to send messages from their own mailbox, and also any results from system objects like mailbox plans.

Revoke Send As permission

Run the following command:
Remove-RecipientPermission <identity> -AccessRights SendAs -Trustee <user>

For example, to revoke Joanna’s Vathis Send As permission for the TEST mailbox, run the following command:
Remove-RecipientPermission "TEST" -AccessRights SendAs -Trustee

Now Joanna can’t send messages that appear to come directly from the TEST mailbox.
To skip the confirmation prompt, use -Confirm:$false.

How people use the Send As permission

Individual users or members of security groups with Send As permission can open their own mailboxes and send messages using the From address of the recipient.
Send As permission doesn’t give a user access to another user’s mailbox. To give an individual or members of a security group access to a mailbox, use the following command:
Add-MailboxPermission <mailbox> -User <user or security group> -AccessRights FullAccess

When you give someone access to a mailbox and Send As permission on the mailbox, that person can open the mailbox using their own credentials, compose new messages, and reply to messages in the mailbox.
An explanation of parameters
You use the Add-RecipientPermission, Remove-RecipientPermission, and Get-RecipientPermission cmdlets to add, remove and view Send As permissions. These cmdlets use the same basic parameters:

Identity This parameter specifies the target recipient. The user or group specified by the Trustee parameter can operate on this recipient.
You can specify any type of recipient. For example:

  • Mailboxes
  • Mail users
  • External contacts
  • Distribution groups
  • Dynamic distribution groups
    The Identity parameter is a positional parameter. The first argument on a cmdlet is assumed to be the Identity parameter when no parameter label is specified. This lets you specify the parameter’s value without specifying the parameter’s name.

Trustee This parameter specifies the user or group to whom you’re granting the permission. This allows the user or group to operate on the recipient specified by the Identity parameter.
You can specify the following types of users or groups:

  • Mailbox users
  • Mail users with a user account
  • Security groups

For the Identity and Trustee parameters, you can use any value that uniquely identifies the recipient.

For example:

  • Alias
  • Distinguished name (DN)
  • GUID
  • Name
  • Display name
  • LegacyExchangeDN
  • E-mail address

Additional Information’s:

Give Users Send As Permission

How to get the list for SMTP address and Last connection time for all the users

This article describes how to use PowerShell Commandlet to get the list for SMTP address and Last connection time for all the users.

Steps to implement the request
Step 1: Run the following to authenticate yourself and import PowerShell commands to your local session:

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange-ConnectionUri -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Image 1

Step 2: Run the Commandlet to get the SMTP address and Last connection time for all the users
Commandlet to get SMTP address:
Get-Mailbox | fl EmailAddresses, identity > C:\Emailaddress.csv

Image 2

Image 3

Image 4

Commandlet to get Last connection time:
Get-Mailbox -ResultSize unlimited | Get-MailboxStatistics | select-object identity,lastlogontime,lastlogofftime,DisplayName | sort-object DisplayName -descending | export-csv C:\Lastlogontime.csv

Image 5

Image 6

Image 7

Enjoy Wink

Microsoft Exchange 2013 Public Folders Migration Scripts

    Microsoft recently release the necessary support scripts to migrate Exchange 2007/2010 Public Folders to Office 365.

Microsoft Exchange 2013 Public Folders Migration Scripts

  • Use these scripts to migrate public folders from Exchange 2010 or 2007 to Exchange 2013.
  • In order to migrate Exchange 2010 or 2007 Public Folders to Exchange 2013 on O365, we need to analyze the existing
    Public Folder hierarchy for size to figure out the number of Public Folder mailboxes that are required on O365 and the distribution of folders across mailboxes.

Microsoft Exchange 2013 Public Folders Directory Sync Support Scripts

  • Use this scripts if you need to do one of the following 
  • Initial creation of mail enabled public folder objects in the destination Active Directory for public folder migration from Exchange 2007 or 2010 to Exchange 2013
  • Synchronization of mail enabled public folder objects from cloud to on premise Active Directory
  • Synchronization of mail enabled public folder objects from on premise to cloud Active Directory
  • Synchronization of public folder mailbox objects from cloud to on premise Active Directory