Removing unlicensed users in Office 365

I was faced with a situation where I had 17,020 users that synced up into Office 365 but my Office 365 license was like about 5…

So one of the quickest paths I took was to fire up PowerShell and remove all users that did not have a license.

These are the steps I took to get the job done:



Type in your Office 365 Global Admin credentials:


Get-MsolUser -all | Where-Object {$_.isLicensed -ne "true"} | Remove-MsolUser -Force


Anyway, curious to see the rate it deleted the users, I thought of monitoring the process by opening another PowerShell window and ran this:


Type in your Office 365 Global Admin credentials

Get-MsolUser -All | measure


Turns out the above command took three minutes to run (around 15,600 users) and deleted approximately 36 users per minute. The above command, will progressively run faster as the user count goes down.

Once I’m done, I’ll be configuring up the DirSync version of Forefront Identity Manager 2010 R2 (FIM) to selectively sync a few of the choicest users in my AD infrastructure.


ULS log viewer for SharePoint 2013

Good news for all the on-premises SharePoint Infrastructure Admins and Developers. An improved ULS Log viewer for SharePoint 2013 has been released a few days ago. I was concerned for a couple of years that there wasn’t any movement on updating my number 1 favourite SharePoint tool. However, I did see a video where Bill Baer there was a hint of how bad the tool was and they’d do something about the tool.. so here it is – a new ULS Log Viewer……

Download it here:

Some new features:

1. Monitor multiple servers simultaneously


2. Locate specific log entries via command line

3. Highlight and personalise the output if a filter match occurs

Some fixes I have noticed:

1. More stability when working with the filters

2. Multiple fixes such as filtering on pause state


Can we use it for SharePoint 2010?

Yes! It works well for SharePoint 2010. However, you would need to ensure that .NET 4.5.1 is installed on the server you run ULS Viewer on. With SharePoint 2010, .NET 3.5 is used and you might not find .NET 4.5.1 on your SharePoint 2010 servers.

Download Microsoft .NET Framework 4.5.1 (Offline Installer) here:

I have tested it successfully on Windows Server 2012, Windows Server 2012 R2 and Windows Server 2008 R2.

OneDrive for Business Groovy sync tool

Previously known as SkyDrive Pro, now more appropriately named OneDrive for Business, builds on a solid foundation of years of sync technology.

In terms of functionality, I am quite impressed with the OneDrive for Business functionality. It keeps getting better with each new release.

I use my OneDrive for business syncing various SharePoint Document Libraries with multiple organisations in different folders on my laptop…quite handy for people on the move.

Download OneDrive for Business standalone sync client for SharePoint 2013 and SharePoint Online.

Click here to download OneDrive for Business:

Use the license key:
When I set up my OneDrive for Business, I normally choose to use the license key rather than using my O365 login to install the app. Here is the license key: 3V9N8-W93CC-FQPB8-Y9WVF-TVGJ3


There are some limits on syncing OneDrive for Business and site libraries, according to the OneDrive for Business help:

Note the following limitations related to syncing OneDrive for Business and other site libraries to your computer:

  • You can sync up to 20,000 items in your OneDrive for Business library, including folders and files.
  • You can sync up to 5,000 items in site libraries, including folders and files.
  • In any library, you can download files up to 2 GB.

OneDrive for Business is Gold:
It’s nice to see good ol’ Groove Networks still carrying on behind the scenes and Microsoft building upon a solid foundation of sync software, positively looking at it. :)

Personally, I have been very impressed by Groove since it was released! Groove was brilliant and way ahead of others at that time.

Take a look under the bonnet:


Love it!


Groove Logo:



Well, One Drive for Business certainly is not a new kid on the block. I suggest you give it a try if you haven’t in its newest incarnation!

Troubleshooting Site Mailboxes SharePoint 2013 & Exchange 2013

When configuring Site Mailboxes in SharePoint 2013 on-premises, you may be presented with a few errors such as:

‘Your SharePoint Server configuration is not supported’

Your Organization’ SharePoint Server configuration is not supported. Please contact your system administrator for more information.

Site Mailboxes finally work:


Another error that is displayed is:

Sorry, something went wrong

An unexpected error has occurred.


To troubleshoot these errors, open your favourite ULS Log viewer and look up the Correlation ID.

With Site Mailboxes, there are specific ‘error codes’ or ‘error keywords’ that will be found in the ULS logs.

Here is a table that I found useful when troubleshooting SiteMailbox configuration issues:


Please review the following table if you encounter issues.

Table of error codes for reference when you run a configuration checklist script

Error Code Error Notes
0 NoError Review Prerequisites.
1 ExchangeClientNotAvailable EWS client was not found on the SharePoint WFE. Run the Check script and ensure the entries are properly in the GAC; you may need to reinstall the EWS client.
2 UnsupportedVersion EWS client version is incompatible with SharePoint. Run the Check script to ensure the version meets minimum requirements. Alternatively, the Exchange server may be 2010 or earlier.
3 InvalidUser The TeamMailboxDomain parameter is not a valid FQDN or SMTP address.
4 UnauthorizedUser The script received a 401 from the Exchange Server, review the Exchange setup steps.
5 ServerBusy Exchange timed out during AutoDiscovery. It should be intermittent, please retry, but if it is persistent, follow-up with the Exchange Administrator.
6 URLNotAvailable AutoDiscovery failed to return a URL for ECP/OWA, which means typically that the EWS client version is incompatible with SharePoint. It may also mean Site Mailboxes are not enabled on Exchange, which would require follow-up with the Exchange Administrator.
7 OAuthNotSupported Unsuccessful in generating an OAuth token on behalf of SharePoint. This is typically caused by claims-based authentication being disabled on the SharePoint web application.
8 OAuthException An error occurred during the OAuth handshake between SharePoint and Exchange. This is typically caused by server to server configuration issues, such as a realm value mismatch on either side, certificate issues for Exchange or SharePoint, etc. Review certificates and attempt to establish or reestablish trust.
9 InvalidAutodiscoverDomain The AutoDiscover domain property is not set to a valid FQDN.
10 UnknownError An unknown error condition has occurred. Run the Check script and confirm that a valid, trusted instance of SharePoint is available, review prerequisites, confirm AutoDiscover has been set-up properly with the Exchange Administrator.
101 OAuthNotSupportedOverHttp If this error is thrown, your web application’s default zone is not set to SSL, and AllowOauthoverHttp is also set to false. Run the Check script to ensure that any web application you intend to host site mailboxes are set with SSL in the default zone, as outlined in the prerequisites.
102 AssociatedOwnersGroupNull One or both of the default Owners and Members groups for the site have been deleted. Each of these two default groups are required to exist on any site where users install site mailboxes. A site administrator should be able to direct a site owner to recreated these required groups.
103 ExchangeTeamMailboxDomainNotSet The ExchangeTeamMailboxDomain property has not been set.
104 ExchangeAppPrincipalNotFound No Exchange app principals were found to be trusted. Typically, this means the New-SPTrustedSecureTokenService step was missed. Run the Check script and ensure that the app principal URL(s) outputted are the correct one(s).
105 ExchangeAppPrincipalMissingPermissions The Exchange app principal being connected to doesn’t have the right permissions on the SharePoint farm. Run the Check script and ensure that the Exchange app principal has the required permissions on the farm.

From <>

In my case, I had an Error 104 – ExchangeAppPrincipalNotFound.

No Exchange app principals were found to be trusted. Typically, this means the New-SPTrustedSecureTokenService step was missed. Run the Check script and ensure that the app principal URL(s) outputted are the correct one(s).

I rechecked my OAuth trust settings with Exchange 2013 and I had an issue with the Enterprise partner configuration.


IISRESET across SharePoint farm servers

Here is something I use when I want to perform an IISRESETacross an entire SharePoint farm. Its useful if you have a large SharePoint farm.
Oh – yea, this will take down your farm while the IISRESET is restarting the services, so its best to test this on a non production environment first. Ensure you have an outage/agreed maintenance window to perform this task on a production farm.

All you got to do is spin up PowerShell on any SharePoint server in the farm and run this:

Write-Host -ForegroundColor Blue “IIS will  be reset across the entire farm”
Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
[array]$servers= Get-SPServer | ? {$_.Role -eq “Application”}
$farm = Get-SPFarm
foreach ($server in $servers)
     Write-Host -ForegroundColor Yellow “Attempting to reset IIS for $server”
        iisreset $server /noforce “\\”$_.Address
        iisreset $server /status “\\”$_.Address
        Write-Host -ForegroundColor Green “IIS has been reset for $server”
Write-Host -ForegroundColor Green “IIS has been reset across the SharePoint Farm”
Start-Sleep -Seconds 5



Retrieve / Decrypt lost password from Application Pools in IIS SharePoint

If you don’t have access to your organisations password safe or if you or your team mate has forgotten to add a password to a certain service account used in SharePoint, it is possible to retrieve the password from IIS!

There is a way to find out the application pool identity password via command line thanks to the inetsrv appcmd! :)

Open IIS and take note of the application pool name that runs the application pool identity with the password you want to retrieve.
In my example, I have demonstrated the extract of the “SecurityTokenServiceApplicationPool“, which runs the SharePoint farm service account as its identity. So, if you are after another application pool, please replace this with the corresponding Application Pool name in your IIS.

Keep in mind – this works for any IIS application pool – SharePoint web app, SharePoint service applications or non SharePoint IIS / .NET sites application pools!

Open a command prompt and run this:

&$env:windir\system32\inetsrv\appcmd.exe list apppool "SecurityTokenServiceApplicationPool" /text:ProcessModel.Password


Configure IP forwarding for NLB PowerShell

There are advantages of having two Network Interface Cards – NICs on webservers – specially with SharePoint, since I work with SharePoint most of the time (some other open source products too!).

When configuring ‘Unicast’ NLB mode, Unicast takes over the NIC, thats why we used to create two NICs and set up IP forwarding so that requests that arrive on one NIC (Public) are sent to the other NIC (Private) connected to the other servers in the domain.

Here are the steps I follow to configure NLB and IP forwarding between the two NICs (multi-homed computer for the experienced). 😉

1. I usually rename the first NIC as “Private”.

2. Add a new NIC and call it “Public”.
Configure an IP address and Subnet mask. Do not configure a default gateway on the Public NIC.

3. Configure the Windows NLB cluster.
In Windows Server 2012, to add the NLB feature:
Add-WindowsFeature -Name NLB
Add-WindowsFeature -Name RSAT-NLB
Configure the Windows NLB cluster (google up for more info)

4. Configure IPv4 forwarding via PowerShell:
Set-NetIPInterface -InterfaceAlias Public -AddressFamily IPv4 -Forwarding Enabled

5. Point your DNS A record to the IP of the ‘Public’ NIC.

Have you tried the Merge-SPLogFile command when troubleshooting?

When troubleshooting SharePoint issues, the best way to filter out all the noise from your log files and sort it for easier troubleshooting is to use the ULS Log viewer tool.

Refer to my blog post on the ULS Log viewer comparison and verdict to get a feel for the other options and see how I got to my conclusion there.

However, this ULS Log viewer tool does not display logs from other servers in the SharePoint farm, unless obviously its a single server farm.

The way to help you with a multiserver farm is to run the Merge-SPLogFile command in the SharePoint management shell. This command “merges” all logs from other servers in the farm and combines them into one ULS log file on the local server. That file can then be opened in your favourite ULS log viewer for troubleshooting.

Note: this works in both SharePoint 2013 and SharePoint 2010.

So how do we use it?

Here is an example of how I use it to grab all logs between say 10AM and 10:30AM on the 23rd July 2013:

Merge-SPLogFile -Path "D:\Temp\MergedLog-20130723-1000-1030.log" -StartTime "23/07/2013 10:00:00" -EndTime "23/07/2013 10:30:00"

If I know the correlation ID, then I would recommend you run the following command after updating it to your correlation ID:

Merge-SPLogFile -Path D:\Temp\MergedLog-419ac99c-81b2-0077-378d-3c23767d2955.log -Correlation 419ac99c-81b2-0077-378d-3c23767d2955




Merge-SPLogFile looks across all the servers in the farm, aggregates the logs with the correlation ID and creates the aggregated .log file.

The merged log file containing only the  information you specified and require. In this case, a certain correlation ID.

The merged log file containing only the information you specified and require. In this case, a certain correlation ID.


Open the log file up in ULSViewer!

Open the log file up in ULSViewer!


There are a lot more examples of what you can do with Merge-SPLogFile you can get by typing this in the SharePoint management shell:

Get-help Merge-SPLogFile -examples Continue reading 

SharePoint 2013 SQL “best practices”

Note – this blog post has a title ‘best practices’. I named it so to match the referred TechNet article entitled “Best practices for SQL Server in a SharePoint Server farm”. So please forgive me for using the term ‘best practices’. Probably ‘guidelines’ or ‘good practices’ is a better name for this article.

Getting back to the topic: Some times you need a refresher when it comes to guidelines in setting up SQL for SharePoint – especially when setting up the newer SharePoint 2013.

There is a Technet article I would like to refer to here which specifically refers to ‘best practices’ for SQL server in a SharePoint 2013 environment. There are a few changes to note when it comes to SharePoint 2013.

A couple of important things to note:

Do not enable auto-create statistics on a server that hosts SQL Server and SharePoint Server. Enabling auto-create statistics is not supported for SharePoint Server.

Set the MAXDOP (max degree of parallelism) setting to 1 and nothing else. Setting the max degree of parallelism to any other number can cause a less optimal query plan to be used that will decrease SharePoint Server 2013 performance.

There is also some guidance on setting up the SQL instance for better performance and managing the SharePoint databases.

Here’s the article for further reading: