Follow me on Twitter @AntonioMaio2

Monday, August 31, 2015

After Azure ADConnect - Activating Office 365 Users Through PowerShell

Many enterprises are looking at hybrid scenarios as part of their journey to a cloud based infrastructure, and one of the base scenarios or requirements for a hybrid cloud deployment is the synchronization of corporate identities (user accounts) from an on premise Active Directory (AD) environment to Office 365.  I've written several articles on this topic, and I often talk about 2 critical steps in the process:

  • Preparing on premise AD by cleaning up user account properties (before synchronization)
  • Activating synchronized user accounts in Azure AD (after synchronization)

Both operations can be performed manually in your on premise AD administration console, and in the Azure AD administration console in Office 365.  However, when you're dealing with a moderate to large number of users its often in practical to use the administration console GUIs for either step.

Activating Office 365 Users Through PowerShell

In this post I'll talk about how you can use PowerShell to activate Office 365 users once they're synchronized to Azure AD.

When synchronizing users with Azure ADConnect, the server hosting ADConnect will automatically have Windows Azure Active Directory Module for Windows PowerShell installed as part of that deployment, which is the PowerShell module you'll be using.  You can run the following PowerShell commands on that server.  Alternatively you can download and install the following 2 components:

  • Microsoft Online Services Sign-In Assistant (download here)
  • Windows Azure Active Directory Module for Windows PowerShell (download here)

We'll begin by connecting to your Office 365 tenant.

Connecting to Office 365

  • Launch Windows Azure Active Directory Module for Windows PowerShell.  Ensure you launch it as an Administrator.
  • Connect to your Office 365 tenant by using Connect-MsolService.  This command does not take any parameters.
  • A dialog will popup asking you for your service administrator username and password.  Enter them and click OK.  Once successfully connected, your PowerShell window will look like the following:
  • To view the list of available PowerShell commands with this module type Get-Command -Module MSOnline.

Get a List of Office 365 Users

  • To retrieve a list of Office 365 users you can use the command Get-MsolUser.  This will display a list of all users in your Office 365 tenant, including their User Principal Name, Display Name and whether or not they have a license.  Notice how both licensed and unlicensed users are shown in the following list:

  • If you only wish to see a list of unlicensed users then you can call the same command with a parameter for unlicensed users only:  Get-MsolUser -UnlicensedUsersOnly.

  • If you are working with a large number of users, consider using the -MaxResults parameter along with the -UnlicensedUsersOnly parameter.  For example, you can call: Get-Msoluser -UnlicensedUsersOnly -MaxResults 1000.  If -MaxResults is not specified, a default value of 500 is used.

Activating Office 365 Users

Before you can activate Office 365 users, we must first set the location of each user.  Microsoft requires this because the services it can offer to users is based on their location.

  •  The 2 character country code is used to set a location for each user.  So for Canada you use "CA" and for the United States you  use "US".  Other applicable country codes can be found here: two letter ISO code list.  You can set the location for an Office 365 user by calling: Set-MsolUser -UserPrincipalName "<user's upn>" -UsageLocation "US"

Here we specify the user by specifying their UPN by using the -UserPrincipalName parameter.
  • Once you have set a location for each user, you'll now require the name of your license SKU.  You can find this information by calling Get-MsolAccountSku.  This will return a string that's typically named <domain name>:ENTERPRISEPACK as in the following example:

Notice, the number of active units (available licenses), warning units and consumed units (assigned licenses) are displayed.  The number of licenses available to you will be Active - Warning - Consumed.  So in my case I have 19 licenses available that I can assign.

  • To assign a license to a specific user use the following PowerShell command: Set-MsolUserLicense -UserPrincipalName "<user's upn>" -AddLicenses "<your license SKU>".  After running this command and then running Get-MsolUser again we can see that our user now has a license, as in the following example:

Combine PowerShell Commands to Activate Users in Bulk

We can combine the PowerShell commands shown in order to assign a location and license to users in bulk, as in the following examples:

  • Get-MsolUser -UnlicensedUsersOnly | Set-MsolUser -UsageLocation "US"
  • Get-MsolUser -UnlicensedUsersOnly | Set-MsolUserLicense -AddLicenses "<your license sku>"

Azure ADConnect provides a fantastic tool for synchronizing users from on premise Active Directory to Office 365 and keeping them synchronized.  However, activating users is still a critical step in enabling users to access Office 365 services, and when activating users in bulk using PowerShell will save considerable time over using the administration console GUI.


Monday, August 24, 2015

DFW SharePoint User Group: Hybrid Identity Management in SharePoint and Office 365

Thank you to everyone that came out to the Dallas Fort Worth SharePoint User Group meeting last week on Tuesday August 18th.  We had a great crowd and I hope everyone enjoyed my presentation on Hybrid Identity Management in SharePoint and Office 365.

The presentation deck can be found here on slide share here:

As mentioned during the presentation, my slide deck does include an Appendix with screenshots of everything I went through.

Demo: User PowersShell to Active Office 365 Users

For those that attended, there was one glitch with my demo when trying to use PowerShell to apply a license to a newly synchronized user in my Office 365 tenant.  The issue with that I was trying to do was that I accidentally typed the PowerShell command Set-MsolUser rather than Set-MsolUserLicense.  This had been correct in the slide deck, and I just mistyped the command.  In any case, the full correct PowerShell command is:

Set-MsolUserLicense -UserPrincipalName " <user’s upn> " -AddLicenses “<your license SKU“

Customizing the User Sign In Page

There was also another correction made in the slide deck: in the table on slide 9 which describes various requirements along with which are supported with Synchronized Identity vs Federated Identity, it previously mentioned that customizing the sign in page was only available with the Federated Identity model.  Earlier this year however Microsoft released the capability to customize the sign in page in Office 365, so this will now work with both Synchronized Identity and Federated Identity models. This capability is only available with the Azure AD Basic or Premium editions, and not the free edition.  So you must pay for Azure AD in order to make this customization.  This fact was pointed out to me by Chris Goosen (Office 365 MVP who attended the meeting) - Thanks Chris!  He's even written a great blog post about how to go about customizing it here:

Please reach out to me if you have any other questions on this topic.


Friday, August 21, 2015

Initializing Azure VMs to Host SQL Server for SharePoint 2013

This is another post designed to help people with some basic steps involved in setting up Azure VMs for a SharePoint farm in a lab or test environment.  As mentioned in a recent post, I often use Azure VMs to test scenarios related to SharePoint 2013. When standing up a brand new SharePoint environment, I might setup a new VM specifically to host my SQL database.  When doing so, I'll often quickly create a VM using a SQL Server template in the Azure VM Gallery.

As part of this process, Azure will ask me to specify a network (which I already have configured in my Azure instance) and an administrative user account.  I cannot seem to specify a domain account here since the new server will not yet be domain joined.  The administrative user account I do specify is created as a local administrator in my new VM and given ownership over the SQL database which is deployed as part of the template.

Once created, my next step is to domain join this new VM to my domain.  You can see basic steps for how to accomplish that in a previous post here:  Domain Joining New Azure VMs.

At this point, you would think that I could just start installing my SharePoint 2013 Server on a separate VM (using service accounts), and as part of that installation process specify the administrative account I created for SQL as the SharePoint Database Access account (allowing my new SharePoint farm to connect to this newly setup SQL Server VM).  But, there are a few settings you need to configure first related to SQL before you can start setting up SharePoint 2013.

After my SQL Server VM was created, and even after I domain joined it, the only account that I specified which currently has ownership of the database was the local administrator account that was created as part of the VM creation process.  I cannot and should not use that account to setup SharePoint and connect to the database.  I can login to the SQL Server VM as a domain account, but it would not have any administrative capabilities over the database, nor could it connect to the database from a separate server (like the one you're installing SharePoint on).  There is no domain account yet that has that type of access to the database.

Configuring a Domain Account as SQL Sys Admin

Typically the first domain account that you provide access to SQL Server would not be used to install SharePoint. When configuring this domain account to access SQL Server, you often give it the sysadmin server role so that it can have ownership over all databases and be used to perform any operation in SQL Server, including configuring other accounts with appropriate permissions in SQL Server with which to install/configure SharePoint.  This is done by doing the following:

  • Login to the SQL Server VM as the local administrator account that was specified when you created the VM.  
  • Launch SQL Management Studio and connect as that local administrative account.  If you look in the top node of the Object Explorer in this screen shot, you can see that I am logged in as ALMAIOSQL-1\Antonio.Maio which is the local administrator account.

  • In the Object Explorer, open the Security node, then right click on the Login node and select New Login...

  • In the Login - New window, click the Search... button to specify the domain account that you wish to use as SQL administrative account.
  • Specify the domain account, click Check Names, and click OK.

Pretty basic stuff so far!

  • In the Login-New window click the Securables page (top right corner of the page), click Search..., select the The server <SQL Server Name> option, and click OK.
  • Click the Server Roles page, check the sysadmin option.  Click OK.

This account may now be used to create and grant appropriate permissions to other accounts which will be used to install and configure SharePoint 2013 on another server.  Before you can do this, you'll need to logout of the VM, and login again as the domain account you just configured.

Allowing the Database Access Account to Connect to SQL Server

In order to install SharePoint 2013 and specify a Database Access Account, the following is a process that you'll need to go through to give a domain account access to the database.
  • Login to the SQL Server VM as the domain account which you gave sysadmin access to the database. 
  • Launch SQL Management Studio and connect as that domain account. 
  •  In the Object Explorer, open the Security node, then right click on the Login node and select New Login...

    • In the Login - New window, click the Search... button to specify the domain account that you wish to use as SharePoint's Database Access Account.
    • Specify the domain account, click Check Names, and click OK.

  • In the Permissions for <SQL Server Name> list check Grant option beside the Connect SQL permission and click OK.

This account may now be specified when running the SharePoint 2013 install process as the Database Access Account.

There are other service accounts that are also required when installing a SharePoint 2013 farm (setup account, farm account) which have their own requirements for permissions, privileges and being part of local administrator groups.  Its important to understand these requirements when creating a new SharePoint farm and there are some great resources available from Microsoft on the specific requirements of each account:  Account Permissions and Security Settings in SharePoint 2013.


Monday, August 10, 2015

Back to Networking Basics: Domain Joining New Azure VMs

I often use Microsoft Azure VMs to test various scenarios related to SharePoint 2013.  I work with a lot of on premise SharePoint clients and having an environment to quickly try something out is really helpful.  Azure let's me of course quickly spin up VMs using one of the templates from the gallery and get up and running quickly.  I have my own environment with several servers already setup in Azure, all within my own domain, and I often add a new server when I need to test something really new or experimental (not wanting to mess with my existing servers). 

When I create a new VM, Azure asks for me an administrative user account and password as part of that process, and makes that user a new local admin on the new server.

Once created, the first thing I typically want to do with that VM is domain join it to my domain.  Due to how Azure creates that VM with that local administrator account, there is a couple of extra steps that I need to manually perform (and sometimes forget) when domain joining that server.

These are just some networking basics, but I wanted to share those steps here so that you can quickly get through this process should you run into it.

When I connect to my new VM, and want to domain join it I typically use the following steps:
  • Open Windows Explorer
  • Right Click on This PC
  • Select Properties
  • Within the System page which appears, under the "Computer name, domain and workgroup settings" section, click Change Settings

  • Click the Change Button
  • Select the Domain radio button, enter my domain name and click OK
However, at this point, if you are in a new shiny Azure VM you'll often run into this error:

This error means that Windows Server does not know where to find your domain controller in order to contact AD and join the domain.  This happens even if you've created a 'network' within Azure and you selected that network when creating your new VM.  So let's look at how you tell it where your domain resides.

  • Right click on your Network icon in the task bar
  • Select Open Network and Sharing Center

  • Click on Change adapter settings
  • Find the Local Area Connection, right click on it and select Properties

  • Within the Ethernet Properties dialog, select and select the Internet Protocol Version 4 (TCP/IPv4) option
  • Click the Properties button
  • In the Properties window, select the Use the following DNS server addresses radio button, and enter the IP address of your AD Domain Controller VM as the Preferred DNS Server, and the IP address of your Default Gateway as the Alternate DNS Server as shown in the following.  You can find both of these IP addresses by connecting to your AD Domain Controller VM and running ipconfig at the command prompt.
  • Once entered, you can click the Advanced button shown, navigate to the DNS tab and you'll see these 2 IP addresses already added.

  • Click OK, OK and OK to exit out of these dialogs.

Your VM will now know where to look to find your domain controller when adding this server to your domain.  Return to Windows Explorer, right click on This PC, click Properties, click Change Settings and try to add your new VM to your domain now.

Enjoy your new Azure VM!