So you’ve purchased Microsoft’s Enterprise Mobility Suite (EMS) licenses, now you need to assign them to users within your organization. A typical situation will be that you already have Office 365 licensed users, and it make sense that all of them will get EMS licenses too.

To achieve this, I would suggest using an Azure AD group with Dynamic Group membership. in this example, the group will include accounts that match ALL these conditions:

If the module is not well-formed and its location is not included in the value of the PSModulePath environment variable, basic discovery features of Windows PowerShell, such as the following, do not work.

The ListAvailable parameter of the Get-Module cmdlet cannot find the module.

The Import-Module cmdlet cannot find the module. To import the module, you must provide the full path to the root module file or module manifest file.

In my case, I’ve noticed that because I did not modified the PSModulePath system variable, a schedule task of the PowerShell script using that module failed to import the module…. the fun part was that running it in Interactive Mode (while being logged in to the server) actually worked…

The MSILOG indeed showed that the setup was looking for the RTM language files in the original location where the setup files were, but they are long gone… with the RTM DVD no where to be-found (RTM trial files + the oldest Language Pack bundle are in a non compatible version) this situation was doomed to failure.

So, I’ve turned to manually remove any references to the Client / Server language packs on the server, this included removing a whole bunch of registry keys:

And it works ! Now, I guess that with a script this would have been much quicker then the registry method, but at least now I’m (and you are) aware of this workaround , and here’s the script for your usage:

** edit the $setuplocation variable for your directory of the servicepack.

After a few incidents from Office 365 deployments, I’d like to share this issue to help anyone facing it.

If you or anyone of your users tried to send an email and use the “From” option to send as another recipient you might face NDR’s (non delivery reports) which will include these errors:

Delivery has failed to these recipients or groups

This message could not be sent. Try sending the message again later, or contact your network administrator. Error is [0x80070005-00000000-00000000]

Using Exchange Server Error Code Look-up (Download Err.exe), 0x80070005 resolves back to MAPI_E_NO_ACCESS or E_ACCESSDENIED which bring us to the actual cause of the issue.

SendAs / Send-as permissions are not retained in migrations to Office 365 just because it is based on an ACL set in Active Directory and ACLs are not synced to Office 365.

To add a SendAs permission use the Add-RecipientPermission cmdlet with Exchange Online Remote PowerShell or use the Exchange Admin Control Panel and add the Send As permission from the “Mailbox Delegation” menu.

As a result of this issue, I’ve created a small script to report which recipients (of any type) have non inherited SendAs permissions ACL’s. You can later use the report to re-create the permission in 365.

Since Office 365 projects started, setting users` licenses with scripts has been somewhat of an issue.

There are great scripts out there to automate assigning licenses to users, but the prerequisite of assigning an Office 365 license to a user is to choose the Usage Location for that user. When dealing with several dozens or hundreds of users that might be fine, but for large scaled deployments this becomes also an issue. and I’ve decided to script it and share this in case anyone will need this as much as I did.

This script is has a really simple logic, trace down the Country attribute value for each user, match that with the two letter country code (required for the PowerShell Set-MsolUser command) and set that value for the user.

I’ve worked up to match the list from https://www.iso.org/obp/ui to the countries available for selection within the Office 365 portal.

Keep in mind that the script will not handle any spelling errors, so be sure to maintain the country value BEFORE you run this script. If you are using Directory Synchronization this should be more productive as your Active Directory will also benefit from this move…

The script will try to find an exact match of the country value, although – case Insensitive.

Update– 05-02-2015 – Thanks for the feedback about this post, some more work has been done, please download the new version…

Update– 07-30-2014 – Thanks for the feedback about this post, I’ve republished the code. it is now wrapped as a script and also logs results to a log file. download the new version…

I’ve been busy with more Office 365 and Hybrid Exchange Online deployments and came up with a script I hope will help some of you out there.

While deploying an Hybrid Exchange Online setup, one of the steps the Hybrid Configuration Wizard is doing is modifying the email address policy and adding “alias@tenant.mail.onmicrosoft.com” to the relevant EAP policies. This is great although there’s a good chance you have some mailboxes that are set with EmailAddressPolicyEnabled:$false

I’ve written a function script that will help you add the additional secondary SMTP proxy address to those mailboxes easily 🙂

Here’s an example on how to use the script:

.\Add-OnMicrosoftSMTP.ps1 -Tenant:ilantz

The script will require your “Tenant” name, for example – if your Office 365 tenant is ilantz.onmicrosoft.com, enter ilantz as the tenant name. Once entered it will find all mailboxes with the property EmailAddressPolicyEnabled:$false and have no routing SMTP address like *@tenant.mail.onmicrosoft.com (following the default Exchange Hybrid Configuration Wizard settings).
Then the script will add the required SMTP proxy address following the PrimarySmtpAdress prefix, if that SMTP proxy address is already taken, the function will add a random 5 digit number to the prefix – John.Doe12345@tenant.mail.onmicrosoft.com.

The script will catch and display any exceptions that may occur during the process. and will automatically log the results to a log file.

I’ve upgraded my desktop to windows 8 lately and since the upgrade I’ve noticed that each time the computer enters sleep mode or hibernation it keeps turning on my itself mysteriously and no apparent reason.

Well…no more!! Here’s the actual line of events that led me to the solution:

Went through some event viewer entries, specifically looking at Power-Troubleshooter and Kerner-General source that did not provide me with anything…

Double checked that no one is touching the mouse or keyboard… 🙂

Made sure that the “Allow wake timers” option is not enabled for the active power scheme

Disabled the “Allow this device to wake up the computer” option on the network card adapter Power Management settings tab – you can query all devices that are allowed using the following command (cmd not PowerShell):powercfg -devicequery wake_armed

Only after being frustrated again from the computer still waking up with no apparent reason I’ve noticed that it keeps waking up at around specific times, which led me to the conclusion that it’s probably a schedule task that was waking the computer up !
Seems like there is a Media Center task names mcupdate_scheduled that was causing all the trouble !

So, I’ve written a small PowerShell script to disable the “wake the computer to run this task” option from all scheduled tasks at once, and that did the trick!
This script should work fine with Windows 8 or Server 2012 and might serve as an example for manipulating scheduled tasks with PowerShell.