The TexMX Recordhttps://texmx.net
Living in Texas, Loving the CloudsThu, 29 Jun 2017 00:37:15 +0000enhourly1http://wordpress.com/https://s2.wp.com/i/buttonw-com.pngThe TexMX Recordhttps://texmx.net
Managing Office 365 Licenses in Azure AD with the new Azure AD V2 PowerShell Modulehttps://texmx.net/2017/01/12/managing-office-365-licenses-in-azure-ad-with-the-new-azure-ad-v2-powershell-module/
https://texmx.net/2017/01/12/managing-office-365-licenses-in-azure-ad-with-the-new-azure-ad-v2-powershell-module/#respondThu, 12 Jan 2017 15:00:39 +0000http://texmx.net/?p=8623Continue reading Managing Office 365 Licenses in Azure AD with the new Azure AD V2 PowerShell Module→]]>Microsoft recently released a new version of the PowerShell module for administering Azure Active Directory to General Availability.

The previous module used MSOL (Microsoft Online) cmdlets to perform tasks (i.e. Get-MSOLUser). The new cmdlets use the AzureAD cmdlets (i.e. Get-AzureADUser) which leverage the Graph API.

Because of this, you’ll want to make sure you download the latest version of the modules and update your existing scripts accordingly.

Assigning Office 365 licenses with these new cmdlets can be a bit tricky and confusing at first. So, I’ll try to explain the process step-by-step so you gain an understanding of what’s going on.

Understanding licenses in Office 365:

Each license in Office 365 has an associated SkuID and SkuPartNumber and a list of one or more associated ServicePlans.

For instance, the E3 license has a SkuID of 6fd2c87f-b296-42f0-b197-1e91e994b900, a SkuPartNumber of ‘ENTERPRISEPACK’, and is comprised of the following Service Plans:

Service plan

Description

SWAY

Sway

INTUNE_O365

Mobile Device Management for Office 365

YAMMER_ENTERPRISE

Yammer

RMS_S_ENTERPRISE

Azure Rights Management (RMS)

OFFICESUBSCRIPTION

Office Professional Plus

MCOSTANDARD

Skype for Business Online

SHAREPOINTWAC

Office Online

SHAREPOINTENTERPRISE

SharePoint Online

EXCHANGE_S_ENTERPRISE

Exchange Online Plan 2

You can get a listing of the friendlier Descriptions for each of the SkuPartNumbers from TechNet here.

When you assign an E3 license to an individual user, you can choose to exclude one or more Service Plans so they don’t get access to those services.

Assigning Licenses in PowerShell

Each Office 365 tenant has a unique TenantID that looks similar to the SkuID or any other GUID. In our example below, the TenantID is 85b5ff1e-0402-400c-9e3c-0f9e965325d1.

To get a list of the SkuIDs you are subscribed to in your Office 365 tenant, connect to Azure AD using the Connect-AzureAD cmdlet. Then, run:

C:\> Get-AzureADSubscribedSku

You’ll get returned a list of ObjectIDs, SkuPartNumbers, PrepaidUnits and ConsumedUnits, showing how many licenses from each Sku have already been assigned (see example below from the online documentation for Get-AzureADSubscribedSku). The ObjectID is made up of the TenantID, an underscore, and the SkuID for each subscription you have purchased:

If we also wanted to assign, for instance, EMS licenses to the user in addition to the E3 license, we’d repeat the process above and create a second AssignedLicense object and add it to the AddLicenses property of $AssingedLicenses. I’ve done this below for brevity:

Now that we’ve got an object that contains a list of all the licenses and excluded service plans, we’re ready to actually assign these licenses to your user(s). To assign the license, simply run the Set-AzureADUserLicense cmdliet, providing the $AssignedLicenses variable:

But you’ll have to add an Office 365 commercial account or on-premises Exchange 2016 mailbox to be able to use it.

This feature is well-known in Outlook desktop clients; and it’s always worked regardless of whether your mailbox is on Office 365 or Exchange on-premises.

On a somewhat related note, Microsoft finally completed the move from AWS to the Microsoft Cloud for the back-end infrastructure supporting this app. That goes a long way to easing many corporate security concerns.

New for Exchange 2016 only, is the option to download the updates as a single ISO file instead of a self-extracting package. Copying a single ISO over the network from one server to another is quicker and more efficient than copying the self-extracting package or the thousands of extracted files.

Updates of note this time around:

Updated OWA S/MIME Control certificate

New distribution package for Exchange 2016

Change to mailbox anchoring for remote PowerShell

17 new languages supported for OWA

Support for Standalone Hybrid Configuration Wizard in Exchange 2010

Microsoft is working on building in support for .Net 4.6.1 in the next quarter’s Cumulative Updates. So, avoid installing that version of .Net on ANY Exchange server for the time being.

For more info and download links for the updates, follow the links below:

As a side note, yesterday (March 14th, 2016) marked the 20th anniversary of the first public version of Exchange (v4.0) Released To Manufacturing (RMT’d).

It’s been a long journey from the old MS Mail to Exchange Online/Office 365. Here’s to the next 20 years!

Happy Birthday Exchange Server!

]]>https://texmx.net/2016/03/15/march-2016-quarterly-updates-for-exchange-released/feed/0davidsmith71Disable Audio/Video functionality for Skype Users via PowerShellhttps://texmx.net/2016/03/10/disable-audiovideo-functionality-for-skype-users-via-powershell/
https://texmx.net/2016/03/10/disable-audiovideo-functionality-for-skype-users-via-powershell/#respondThu, 10 Mar 2016 19:51:24 +0000http://texmx.net/?p=8585Continue reading Disable Audio/Video functionality for Skype Users via PowerShell→]]>Like my previous post on Exchange Mailbox Protocols, many companies limit the ability of some of their users (but not all of them) to use the audio/video functionality built into Skype for Business Online. Normally, this occurs in office environments that don’t have the internet bandwidth to support all that A/V traffic for a large number of users, so they limit that use to those who need it or executives, VIPs.

Unfortunately, it’s not possible to create a SIP profile that enables/disables the protocols for any user to which its assigned. Therefore, administrators must disable this functionality for each individual user. This is easily done for one or two users via the administrative console web page, but doing this in bulk requires PowerShell.

To help alleviate this, I’ve created a script that leverages security groups in Azure AD (and on-premises AD if they are synchronized via DirSync) as a way to indicate which users should be allowed the use of Audio/Video functionality in Skype for Business Online.

By default, the script will assume your group is named Office365-AllowSkypeAV, but you could use any group name you want and feed that to the script via a command-line parameter.

When run, the script will disable AudioVideo functionality for ANY user who is NOT a member of the above referenced groups.

This script also leverages my WriteTo-Log function so that a running log can be generated keeping track of each change made to each user for auditing purposes.

Finally, there are optional command-line parameters (-From, -To, -SMTPServer) that can be used to ensure the log is emailed to an address of your choice after completing.

]]>https://texmx.net/2016/03/10/disable-audiovideo-functionality-for-skype-users-via-powershell/feed/0davidsmith71Disable Exchange Mailbox Protocols via PowerShell Scripthttps://texmx.net/2016/03/09/disable-exchange-mailbox-protocols-via-powershell-script/
https://texmx.net/2016/03/09/disable-exchange-mailbox-protocols-via-powershell-script/#commentsWed, 09 Mar 2016 19:30:52 +0000http://texmx.net/?p=8577Continue reading Disable Exchange Mailbox Protocols via PowerShell Script→]]>Many companies limit the ability of some of their users (but not all of them) to leverage all of the default protocols enabled for accessing a mailbox in Office 365/Exchange Online while still allow them to connect with Outlook via MAPI.

Unfortunately, it’s not possible to create an OWA profile or a POP profile, for example, that enables/disables the protocols for any user to which its assigned. Therefore, administrators must disable these protocols for each individual user at the CASMailbox-level.

To help alleviate this, I’ve created a script that leverages security groups in Azure AD (and on-premises AD if they are synchronized via DirSync) as a way to indicate which users should be allowed the use of a certain protocol.

By default, the script will assume your groups are named as listed below, but you could use any group name you want and feed that to the script via a command-line parameter.

Office365-AllowActiveSync

Office365-AllowOWA-Device

Office365-AllowIMAP

Office365-AllowPOP

When run, the script will disable the protocols for ANY user who is NOT a member of the above referenced groups.

This script also leverages my WriteTo-Log function so that a running log can be generated keeping track of each change made to each user’s mailbox for auditing purposes.

Finally, there are optional command-line parameters (-From, -To, -SMTPServer) that can be used to ensure the log is emailed to an address of your choice after completing.

I’ve discovered that if I used this function as I’d designed it originally, I couldn’t use it in a script that ran as a scheduled task since there’s no History in the $MyInvocation variable to draw from to name the log file. So I re-wrote the function to accomodate this in the following way:

If NO -Logfile parameter is passed to the function within a script, it will automatically name the resulting log file as originally described below

If the -Logfile parameter IS passed to the function within a script, it will use the string value passed to it as the log file name to write to.

If a $Script:Logfile variable is defined in the body of the script, and the -Logfile parameter is NOT passed in the script, the function will always use that string value defined.

This allows me to write a script and configure it to run as a scheduled task. Then I just define a $Script:Logfile variable once at the beginning of the script like this:

This insures my script always uses the same log file name while it’s running and doesn’t have to rely on HistoryID.

I write a LOT of PowerShell scripts for my clients on almost every engagement I’m on. It’s not unusual for one of those scripts to execute a command or lots of commands against a lot of user accounts.

In order to ensure I can keep track of what changes are being made to which users, and when the change was made, it’s helpful to have a log file for each execution of a script.

That’s why I wrote my own PowerShell function called WriteTo-Log. This function creates a log file named with the date & time of the script execution, then the file name of the script (minus the extension) and adds a .log extension and places that log file in the same directory from which the script was executed. (note – not the same directory the script resides, but the directory from which the script was executed)

Example file name: .\2016-01-12-03.22-test-script.log

If you prefer the script use a different file name, you can use the -FileName parameter and pass your own file name to the script each time you invoke the function.

Each time the function is called, a new line is added to the log file with a date/time stamp and whatever string you pass to the function. You can also add Foreground and Background color formatting and use the optional -OutputToScreen switch parameter to also echo the line out to the screen for easy review.

Example log entry: 2016-01-12 03.22.32 : Found a file!

The function can be easily copied/pasted at the beginning of every script I write. Then whenever the script takes an action on a user account, I can execute my WriteTo-Log function and pass to it the details of the user and any success/fail results.

I’ve found that running this function in the ISE can cause problems because the ISE doesn’t like or support the Foreground & Background parameters the way I have implemented them. For best results, save your script to a .ps1 and run it in a separate PowerShell window.

You can find the script an an example use below. You can also find the script in the TechNet Gallery

This was because the on-premises send connector to Office 365 was still configured to look for that expired certificate (which had also been deleted already).

The fix was to perform the following:

Open Exchange Management Shell on the on-premises Exchange server

Run Get-ExchangeCertificate, and note the Thumbprint of the correct certificate to be used.

Run $cert = Get-ExchangeCertificate -Thumbprint <thumbprint>

Set a new variable and assign it the concatenated values of the Issuer and Subject values of the certificate (must also include <I> and <S> before each field):$TLSCert = (‘<I>’+$cert.issuer+'<S>’+$cert.subject)