PowerShell

In my previous post I wrote about using Azure automation to start and stop an Azure VM that is deployed using Resource manager. If you did not read that one I suggest you read it first since I will use that setup and the scripts in this post.

The azure automation has a great editor, but there is no version control in it. To solve this Microsoft added an option to integrate with GitHub and Visual Studio Online. For now only the GitHub one is available.

Last week the news came that the migration of IaaS from the classic deployment to Azure Resource Manager went General Available (GA). (https://azure.microsoft.com/en-us/blog/iaas-migration-ga/). Not everything can be migrated yet, see this list for the unsupported features for now (https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-migration-classic-resource-manager/#unsupported-features-and-configurations)

I have a few resources still in the classic deployment model that are supported to move to the new Resource model.

The manual from Microsoft is very good to get you started with updating your PowerShell CmdLets and executing the necessary scripts.

In the trend of my recent blog post I create a new addition to my automation of Office 365 tasks. This time creating a report with the license consumption per month with PowerShell automation, Azure table storage and Power BI. In this post I will take you with me thru the steps to set this up.

What do we need?

Before we can get started coding we need to do some plumbing first. The first thing we need is a storage account. From this storage account we need the connection string.

Last week I was getting complaints by users in our Office 365 environment that the address book in Exchange was not up to date. The issues was that users where getting email addresses with the ‘domain’.onmicrosoft.com as the default email address. The users with these onmicrosoft.com mail addresses where users that are in our on-premises Exchange environment.

The situation

At this customer we have a select group of users in Office 365 and all other users are in an on-premises Exchange environment. A few weeks ago I have updated the AADConnect client to the latest version and everything went well with the update and all users where still in sync with Office 365.

Two weeks after my visit to SharePoint Saturday Paris I visited SharePoint Saturday Netherlands. The schedule for today was a bit more relaxed than in Paris. We had 4 session slots of 75 minutes with great sessions and more time in between the sessions to have a chat with sponsors, trying out the HoloLens and playing some games. The HoloLens is a very cool device and I tried it here for the first time.

In Office 365 we have the option to give some of our users an administrative role, but what role(s) can we give them?

This post will be an overview of the available roles within the portal and PowerShell.

What roles do we have in the portal?

Within the portal we have the following roles available

• Global administrator
• Billing administrator
• Exchange administrator
• Password administrator
• Skype for Business administrator
• Service administrator
• SharePoint administrator
• User management administrator

Microsoft did a great job outlining what each of these roles can do. https://support.office.com/en-US/client/results?Shownav=true&lcid=1033&ns=O365ENTADMIN&version=15&omkt=en-US&ver=15&HelpID=O365E_AssignAdminRoles and scroll down to “Choose which Office 365 admin role to delegate”

On May 28th 2016 I visited SharePoint Saturday in Paris (http://www.spsevents.org/city/Paris/Paris2016/). The event was held in the Montparnasse Tower in the center of Paris on the 40th floor. We had an amazing view from that height.

This article contains my notes of the day.

Start of the day

We had some trouble getting in the building because of some regulations of the building owner, but when we were all registered we could go all the way up to the 40th floor. Here we started with a small breakfast, I did not eat in the hotel so I could use this. I came in just after 8 and all sponsors where getting settled because they also had trouble getting into the building. After breakfast and a delay of 15 minutes the first session started at 9:15

We are rolling out Office 365 at my current assignment. Within this project we want to automate as much as possible to avoid human error and reoccurring tasks. We already used a lot of PowerShell for our current SharePoint farm, so the most obvious thing was to look at PowerShell for automating those tasks. In this article I will take you with me on the journey that we took.

Why Azure Automation

We choose Azure Automation for a few reasons. We started with a few PowerShell scripts from my workstation to see what we could automate and tried to set the default usage location of the user. This is something every user needs before a license can be assigned. We wanted to run this script every 3 hours after the Active Directory synchronization. Our first thought was we can use the Windows task scheduler just like ADSync (We started a year ago with this). The problem with using a task scheduler is that we need to authenticate to Office 365 and we cannot run this script with the current credentials. An option is to just enter the username and password into the script. This is a big NO. Another option was to save the encrypted password and use that one in our script, this one I could not get to work.

Some time back we updated Azure AD Connect at a customer to the latest version. The update itself was an easy one, just next, next finish like they described on the Azure site. But what we found is that the sync engine itself was completely different. The previous version had a Windows timer job as it schedule and ran every 3 hour. You also where able to run that command (DirSyncClientCmd) with a parameter (initial or delta) to run a new or delta sync.

I’m currently working in a large enterprise where we have a dedicated team of SharePoint administrators. This team is responsible for the current on-premises SharePoint environment. The way we give this team control over the whole environment is with the option ‘User Policy’ within the web application. Here we give the whole team administrator rights for the web application. This way we do not have to assign rights to every single site collection.