Category: Configuration

Global Administrator role in Office 365

There are several administrator roles available in Office 365, like the billing administrator, password administrator, service administrator, and user management administrator, but the most important one will probably be the global administrator. The reason for this is because it is the only administrator account that is able to assign other accounts administrator roles.

The account signing up for a new Office 365 subscription will automatically be assigned the Global Administrator role. After signing up, you are free to have more than one global administrator.

In order to assign the global administrator role to an active user, follow the steps below:

  1. Go to http://portal.office.com and log in as a global administrator.
  2. Go to the Office 365 admin center site.
  3. Click the USERS link in the left navigation and choose Active Users.
  4. In the list of Active Users, locate the user you wish to assign the global administrator role to and check the checkbox next to it.
  5. Click the EDIT link to the right below the avatar for the user.
  6. In the left navigation choose the link Settings.
  7. In the section called Assign role, choose the radio button Yes and select Global administrator in the dropdown menu.
  8. Provide and alternate email address for the user.
  9. Hit the Save button at the bottom of the page.

In order to find the all users who have been assigned the global administrator role, you can use the following Windows Powershell.

(Please note that you need to install Microsoft Online Service Sign-in Assistant for IT Professionals RTW first and afterwards Azure Active Directory Module for Windows PowerShell (64-bit version) on the system you are running the script from. Otherwise it will not work.)

$credentials = Get-Credential
Import-Module MsOnline
Connect-MsolService -Credential $credentials
$companyAdministratorRole = Get-MsolRole -RoleName "Company Administrator"
Get-MsolRoleMember -RoleObjectId $companyAdministratorRole.ObjectId

The tenant name in Office 365

The Office 365 tenant name is an important subject to cover before diving deep into the Office 365 world. I would therefore like to take the opportunity to explain what it is, its limitations, and how it works.

When you sign up for an Office 365 subscription, you are asked to provide a domain name which will be your tenant name and used for .onmicrosoft.com. At this point you will have to consider this choice carefully, since you will be unable to change this at a later time. If you want to change the tenant name, you will need to sign up for a new subscription again with a new tenant name.

If you plan to use your trial tenant for production, be sure to choose a name for the tenant that is different from your planned production tenant name. It’s a common mistake to use a company name for the trial. The name of the tenant appears in Lync invites and SharePoint Online, but Microsoft does not currently have tools to rename a tenant or migrate data from one tenant to another. If you change your mind later, you have to create a new tenant and manually move your data and settings. (https://technet.microsoft.com/en-us/library/hh852435.aspx)

The tenant name will be under onmicrosoft.com, which is globally signed. This means that if a company in Europe has already signed up for a domain name called ex. foobar.onmicrosoft.com where the tenant name is foobar, then a company in Asia will be unable  to sign up for the same domain name. This limitation has not always been true. Under the predecessor Business Productivity Online Standard Suite (BPOS), which was the previous name and version of Office 365, the subscriptions was divided into three regions called microsoftonline.com, emea.microsoftonline.com, and apac.microsoftonline.com. But now we only have onmicrosoft.com available in Office 365.

Another important point to consider when choosing the tenant name, is that it will be a part of your SharePoint URL which comes with the Office 365 subscription. Ex. http://yourtenantname.sharepoint.com.

If you want to check whether a tenant name is available for a new Office 365 subscription, I will recommend using the following website: http://office365check.azurewebsites.net.

Cannot complete this action as the Secure Store Shared Service is not responding. Please contact your administrator.

After creating a Secure Store Service Application through the Central Administration interface in SharePoint Server 2013 and trying to access the new Service Application, I receive the following error message from the system:
Cannot complete this action as the Secure Store Shared Service is not responding. Please contact your administrator.

In order to solve this, you can use the following Windows Powershell:

$service = Get-SPServiceInstance | Where-Object {$_.TypeName -eq "Secure Store Service"}
$service.Provision()
IISRESET

The Windows Powershell worked for me, and you should now be able to continue configuring the Secure Store Service Application.

Defining managed paths in SharePoint 2013

A huge part of structuring a SharePoint web application involves creating site collections with sites and having them in a logical structure that reflects different parts of your organisation. Managed paths can help you with just that. Managed paths are a mechanism that enables the user to create uniform navigational structure related to multiple site collections in a farm.

There are two types of managed paths. Wildcard and explicit:

As you can see from the examples above, managed paths are defined per web application and can be created from the Central Administration interface or from Windows Powershell. In this blogpost I will show you both methods from a SharePoint 2013 farm. It is important to point out that neither of these methods are prefered from another. It really depends on the situation.

Using Central Administration

To create a managed path using the Central Administration Interface, do the following.

  1. Open Central Administration and go to Application Management.
  2. In the Web Applications section, click the link Manage web applications.
  3. Select the web application in the list that you want to create a managed path for, and click the button Managed Paths in the ribbon.
  4. This opens up a page where you are able to specify a name for the new managed path and the type.
  5. Click OK to create a new managed path for the web application you selected in step 3.

Using Windows Powershell

To create a managed path using Windows Powershell, you can use the cmdlet called New-SPManagedPath (http://technet.microsoft.com/en-us/library/ff607693.aspx).

  1. Open the SharePoint 2013 Management Shell.
  2. Execute the following: $wa = Get-SPWebApplication -Identity “http://portal“
  3. When the web application has been assigned to the variable, execute the following: New-SPManagedPath “departments” -WebApplication $wa

I hope the information I have described in this blogpost about managed paths helps you understand this important concept in SharePoint.

Unable to open PDF in SharePoint 2010

Today I received a question from a client. “Why am I unable to open PDF files directly from my SharePoint 2010 portal? The system wants me to save the file instead?”. This was an interesting question and I started digging.
I found out that if you have a default installation of SharePoint 2010, the behavior above will occur. SharePoint forces you to save the PDF file and you have no option to open the file directly from within SharePoint 2010.

Luckily you are able to change this behavior by following the instructions below

  1. Go to SharePoint 2010 Central Administration > Application Management > Manage Web Applications.
  2. Select your web application from the list.
  3. Choose General Settings in the ribbon.
  4. Scroll down to Browser File Handling and select Permissive instead of Strict.
  5. Click OK.

You should now be able to open PDF files directly from SharePoint 2010.

The solution above can also be carried out programmatically. This will be a new blog post.