Thursday, July 27, 2017

Getting Started with PowerShell for Administering Office 365

Why Use PowerShell for Administering Office 365?

PowerShell is a powerful and convenient tool for administering Office 365. There are a variety of reasons why you would use PowerShell, including:
  • Adding or editing a large number of records (e.g., users, list items, documents, etc...)
  • Sifting through a large amount of data using filters
  • Exporting data. A common scenario is keeping more than 90 days of audit log data. Audit logs are only kept for a rolling 90 days. One way to keep the data for a long period of time is to export it using PowerShell. For a detailed walkthrough of how to do that, see Paul Hunt's post here: Keeping Office 365 Audit data beyond 90 days with the Microsoft Graph
  • Sometimes PowerShell is the only option. For example, enabling or disabling Office 365 Group creation is done through PowerShell. Also, some government tenants (L4 and L5) do not have an Admin UI and configuration is only done through PowerShell.
This post is meant to be an introduction. It will help you get started with some PowerShell basics for Office 365.


Download The Appropriate Installation Files

First, download and install the Microsoft Services Sign-In Assistant For IT Professionals RTW


Next, download and install the Windows Azure Active Directory Module for PowerShell


There are several different PowerShell modules for the Office 365 workloads. Below are a couple more to download and install:

Connect to Azure Active Directory for Office 365

Open up the Azure Active Directory Module for Windows PowerShell in Administrator mode. To connect to Azure AD in Office 365, type this command:

Connect-MsolService

Enter your username/password and click Enter. If no error comes back, then it connected successfully. Note: you are only connected to Azure AD in your Office 365 tenant. You are not connected to Exchange Online or SharePoint Online.



Get A List of Users and Assign Licenses

Run the following commands:

Get-MsolUser
Get-MsolAccountSku
Set-MsolUser -UserPrincipalName "doug@dough.onmicrosoft.com" -UsageLocation "US"
Set-MsolUserLicense -UserPrincipalName "doug@dough.onmicrosoft.com" -AddLicenses "dough:ENTERPRISEPACK"


The Get-MsolUser command gets a list of all users in the tenant. You can filter the set of users returned to only include unlicensed users by adding the "-UnlicensedUsers" parameter

The Get-MsolAccountSku gets the Office 365 Tenant License SKU.

The Set-MsolUser command sets the user's location

The Set-MsolUserLicense assigns a license to the user.


Enable or Disable Office 365 Group Creation

Frequently, when companies first migrate to Office 365, they don't want users to be able to create their own groups...at least not initially. The following PowerShell scripts turn off the ability to create Office 365 groups for all users.

First, connect to Exchange Online. Exchange doesn't have a separate command module for PowerShell. So, open up the standard PowerShell Window in administrative mode and enter the follow commands:

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


Then, to turn off group creation for all users, run the following command

Set-OwaMailboxPolicy -Identity test.com\OwaMailboxPolicy-Default -GroupCreationEnabled $false


Additional Resources

There are lots of additional resources to help you get started with PowerShell for Office 365:

Thursday, February 9, 2017

MinRole for SharePoint 2016 and the November 2016 Public Update

The Beauty of MinRole

SharePoint 2016 introduced a host of new features, including MinRole. MinRole promised easier administration of SharePoint servers. You can read about how it was touted to simplify deployment, improve performance and reliability, and simplify capacity planning and farm scalability here, All you had to do when you installed SharePoint 2016 was select one of the predefined roles in the configuration wizard:



If you selected "Front-end", "Application", "Distributed Cache", or "Search", SharePoint would take care of installing the appropriate bits and turning on the appropriate services on the server.

Microsoft had learned a lot from running SharePoint at a massive scale in Office 365. They were passing that learning on to us.

The Problem with MinRole

The problem with MinRole at RTM was that it was generally more beneficial for companies that ran large farms (much like Microsoft did in the cloud). If you wanted to run a highly available MinRole farm that also runs workflow and office online server, you would generally need about 15 servers for just one environment:


For many small to mid-size organizations that want to keep their SharePoint environment on premises, this is a lot of infrastructure, especially considering that most organizations need at least two more environments: Staging and Disaster Recovery. MinRole, just wasn't an option...so Custom was the option to select in the Configuration Wizard...no different than how it would be done in SharePoint 2013.

The Solution

Starting with the November 2016 Public Update for SharePoint Server 2016 Microsoft introduced the concept of Shared roles. Instead of each server having 1 of 4 distinct roles, servers could now share roles. So, Front End and Distributed Cache could be combined and Application and Search could be combined. The new configuration wizard now looks like this:


A fully built out, highly available SharePoint 2016 farm using shared min roles was now 11 servers instead of 15, which is a little easier to swallow, especially considering many small organizations don't implement the workflow functionality and would only have 8 servers

Lessons Learned

I really like that Microsoft is leveraging its experience with cloud technologies to bring them to on-premises or hybrid installations. I would love to see more of that. I also like that Microsoft quickly reacted to customers' feedback about the number of servers required for a fully scaled out MinRole environment and made adjustments to suit the needs of the small to mid-size businesses.

Friday, May 8, 2015

Microsoft's Ignite Conference SharePoint Updates and Announcements

As Microsoft's Ignite Conference winds down, there have been several SharePoint-related updates and announcements:

SharePoint 2016 will ship in the second quarter of 2016 and will include the following enhancements:
  •  Patching SharePoint 2016 will require zero downtime! Yay!!! In addition to that, distributed cache is being enhanced to support increased uptime. Microsoft is promising the capability to deliver 99.99% up-time with SharePoint 2016 on premises!
  • SharePoint 2016 will require SQL server 2014 or later
  • There is a new “min role” installation option. This codifies the server role by laying down only the bits it needs to fulfill the role. The roles include Web Front End, Caching, Application, Search, and Specialized.
  • Content DBs will be allowed to scale to TBs
  • The list threshold soft limit will be significantly increased beyond the current 5,000
  • Maximum file size limit will be increased to 10 GB.
  • There is a new “fast site creation” capability which basically creates sites from a “base version” stored in the database. Creating a team site, for example will simply require copying a few rows from the database and will take a matter of a seconds.
In addition to the SharePoint 2016 announcements, there were several announcements for hybrid scenarios:
  • There will be a wizard-like process for setting up and creating hybrid team sites, extranets, and search capabilities
  • Office Graph and Delve capabilities will be enabled for SharePoint on premises beginning with SharePoint 2013 later this year.
  • Microsoft is investing heavily in hybrid scenarios and we can expect to see much more coming in this area.
Windows 10 will be the last “version” of Windows. It will continue to receive small, incremental updates…similar to how other browsers are updated.
One consistent message has been that Office 365 is NOT well suited for traditional

branding customizations (custom mater pages and site definitions). Microsoft continues to take the stance that Office 365 should ONLY be customized through the app model and custom apps.

There still is no good forms story for SharePoint. There was no big announcement. The message remains…use out of the box and InfoPath forms for simple stuff. Use third party tools or custom development for more complex forms
.
OneDrive continues to play a huge role in the Microsoft ecosystem as they try to get enterprises to go to the cloud. Microsoft openly acknowledged that OneDrive for Business has had its share of issues. However, they have stated that improving OneDrive for Business is THE #1 PRIORITY for the SharePoint team.

This is by no means a comprehensive list. I encourage you to check out the session videos on Channel 9: http://channel9.msdn.com/Blogs/MicrosoftIgnite