2mg ativan and 25 mg phenergan can you take benadryl and phenergan together how much phenergan can be given to an 11 yo how many phenergan can i take provigil is addicting provigil for law school


Office365: Using PowerShell to get Office365 license info

Working to apply bulk apply licenses I stumbled upon some useful commands to list the licenses assigned to my Office 365 Account.

The following command will list account Sku ID’s along with the active and consumed units. Best of all list them in a nice grid view

Get-MsolAccountSku |Out-GridView

We can also pull the subset of information such as items include with pack we have.

The following command will list included service plans under our package

Get-MsolAccountSku | Where-Object {$_.SkuPartNumber -eq "ENTERPRISEPACK"} | ForEach-Object {$_.ServiceStatus} |Out-Gridview


Office 365: Cutover Migration | Lost Delegation on Mailboxes

I am posting this to help any of you who are looking to be proactive in your approach to migrate into Office 365 / Exchange Online Services.

After migrating mailboxes info Office 365, you will noticed that under your recipient’s mailbox delegation all previous access levels have been removed. In fact they never came over with the migration in the first place.

But Why?

Because during the copy of the user account and mailbox data this info is not recorded as the migration tools are not designed to copy such info (at this time) “quoting Microsoft support on this one”

Right now I am in search of a method to script out my users and then import that via power-shell. I will post / share this as soon as I have a working solution.

This post is just to inform any of you searching this out that you may also face this same issue.



In my humble opinion as a professional who has been working in Office 365 / Exchange Online – You are better off configuring a Hybrid migration path over the all in one cut-over-method. While the Hybrid may take some extra learning and understanding; its the path that will ensure your data is migrated with all attributes.

Another example of things not working properly in a cut-over migration: Office 365: Convert Mailbox to Shared Mailbox after Cutover Migration


Again note: that not all permissions are preserved when mailboxes are moved to Office 365 using a cutover migration. For example Send As permissions on mailboxes will be lost and administrators will need to reconfigure this once users are moved across into the cloud.

Office 365: Convert Mailbox to Shared Mailbox after Cutover Migration

When performing a cut-over migration the Exchange attribute indicating that the mailbox was a shared mailbox is lost. To correct this I have done the following steps:

List out all of the shared mailboxes form my on-premises Exchange and export them into a CSV file.

Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails SharedMailbox | Select UserPrincipalName | Export-Csv -Path .\shared_mailbox_users.csv -NoTypeInformation

Now prepare the CSV file with the list of user principal names of all mailboxes to be converted. Make sure the column header for the user principal names is “UserPrincipalName”

Now we run the following powershell script to change the mailbox type of all items in the CSV file.

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session

Write-Host "Type in the complete path to the location of the csv. Or you can drag and drop the CSV file onto this window."
$csv = Read-Host

Write-Host "These are the mailboxes in the uploaded list."
$mailboxes = Import-Csv $csv

Write-Host ""; Write-Host ""; Write-Host ""
Write-Host "Continue execution? Y or N"
$permit = Read-Host

If($permit -like "y*")
    $mailboxes | foreach{
        $contextName = $_.UserPrincipalName
        Set-Mailbox $contextName -Type shared -Confirm:$false

Remove-PSSession $Session

Please note

Running Exchange Online Powershell commands / scripts requires you have had installed the Microsoft Online Service Sign-In Assistant, Windows Powershell, Windows Azure Active Directory Powershell

For more info:




Tech Short: Office365 – Convert select on-premises mailboxes to mail-enabled users

When you convert on-premises mailboxes to mail-enabled users (MEUs), the proxy addresses and other information from the Office 365 mailboxes are copied to the MEUs, which reside in Active Directory in your on-premises organization. These MEU properties enable the Directory Synchronization tool, to match each MEU with its corresponding cloud mailbox.

Using the steps provided here I was able to export a list of only user mailboxes and leaving out other mailbox types

Run the following PowerShell command:

Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox | Select PrimarySmtpAddress | Export-Csv -Path .\migration_users.csv -NoTypeInformation

The following full steps of what to do next can be found here: http://community.office365.com/en-us/w/exchange/835.cutover-exchange-migration-and-single-sign-on.aspx

Office 365: Errors during cutover migration

This is an error I’ve received when running a cut-over migration batch in Office 365.

  1. Error: ProvisioningFailedException: The parameters passed to the cmdlet represent a managed account, which doesn‎’t match the namespace state, which is federated.

I’ve reached out to support, to help me troubleshoot this.  So far there hasn’t been much I’ve been able to find online regarding my situation.

More to be shared as soon as I have additional information.

Update – 02/04/2015

With the idea that this may have something do with our domain being federated as we had already setup a ADFS server when we were configured for Hybrid.

So let’s recap on the Error: ProvisioningFailedException: The parameters passed to the cmdlet represent a managed account, which doesn’t match the namespace state, which is federated.

Focusing on the message above I was able to find do some research to research based on some blog searches that indicated the issue was with our federation status.
I ran the following command from our ADFS Server: Get-MsolDomain


Name                                     Status          Authentication
----                                     ------          --------------
jermsmitInc.onmicrosoft.com              Verified        Managed
jermsmit.com                             Verified        Federated
jermsmitInc.mail.onmicrosoft.com         Verified        Managed

I had also reviewed the setting using Get-MsolDomainFederationSettings followd by the federation properties with Get-MsolFederationProperty

Using the Get-MsolDomain I was able to identify that the domain for jermsmit.com was verified and also had a federated authentication status.

I change this back to Managed by running the following command:

Convert-MsolDomainToStandard -DomainName infragistics.com -SkipUserConversion $false -passwordfile c:\password.txt

This was verified by running the Get-MsolDomain to check my results.  And that worked.

I then moved forward by deleting the current failed batch; which took some time.  Once deleted, created a new batch.  At this time the cut-over migration sync is working


– Jermal

Notes:  To run the commands in this post you need connect the active directory power shell to your office 365 account – http://jermsmit.com/azure-active-directory-module-for-windows-powershell-how-to-connect/

$msolcred = get-credential
connect-msolservice -credential $msolcred