How to Enable Unlimited Storage in OneDrive for Business

Last December, it was announced that OneDrive for Business users would indeed be receiving unlimited storage if they had a qualifying subscription. (Details on which subscriptions qualify for unlimited storage can be found in the original announcement here).

Furthermore, I understood from the announcement and the coverage around it that users would initially be enabled with 5 TB, and that if you needed more, you would have to call support and ask for it to be enabled. Presumably this was to discourage users from seeing the infinity symbol for available space, and immediately uploading the contents of their DVD library.

I had been watching my storage stats and checking every month to see if the 5 TB was yet enabled for my account to no avail. I was stuck at 1 TB. My wife also uses our tenant and is an active photographer with quite a few RAW files that she stores in OneDrive for Business. As an aside, she’s very good – you can check out her work at http://www.oliveraphoto.com. Last week, her storage exceeded 1 TB, and OneDrive for Business started complaining. It was time to do some digging.

As it turns out, my understanding wasn’t exactly correct. You are entitled to unlimited storage, but you will only be given the 5TB cap when you ask. You can ask anytime however. In order to get more than 5 TB, you ask for that too, but you can only ask when your storage is in the warning zone – close to 5 TB.

You might think that being Canadian, I’m fine with just asking politely, but patience is not my strong suit. The good news is that you can use the SharePoint Online PowerShell module to connect to your Office 365 tenant, and change the limit yourself. It’s not particularly easy though, so I’ll walk through the required steps, or at least the steps that I required.

1. Install the SharePoint Online PowerShell management shell

The SPO management shell is a PowerShell extension that allows you to connect to SharePoint Online and use PowerShell to perform administrative functions. It’s not installed by default, but it can be downloaded and installed from the Microsoft Download Center here. The odd thing is that it prompts you to choose from 2 different files, 2 for 64 bit systems, and 2 for 32 bit systems.

image

I’m not sure what the differences are aside from the bit level, but I grabbed the most recent 64 bit version and installed it.

Once installed, you must run the shell as an administrator, otherwise, it will fail to find the extension files. I also had all sorts of trouble running it on Windows 10 machines. After trying on 2 different ones, I gave up and installed it on a Windows 8.1 virtual machine, where it ran correctly.

2. Connect to your tenant with admin credentials.

From within the management shell, the first thing that you need to do is to connect to your tenant. You do so by running the Connect-SPOService cmdlet. The syntax is:

Connect-SPOService -Url https://youradmintenant.sharepoint.com -credential adminuseremailaddress

Neither one of the parameters is as simple as it may seem.

The –Url parameter is the administrative url of your Office 365 SharePoint tenant. Normally, it’s the standard SharePoint url with “-admin” appended on to the end of the first identifier. If you normally access SharePoint online with the url https://coolcompany.sharepoint.com, your admin url is https://coolcompany-admin.sharepoint.com.

The –credential parameter is also not quite what it seems. You need admin access to your tenant to run these command, and chances are If you are reading this, then you are. If not, you have to at least provide the credentials of an account that does have admin access. The credential is in the form of an email address, and you will be prompted  for a password when the command is run. This is where I ran into another difficulty.

If you have admin credentials to your tenant, it’s that much more important that your account is secure. One of the best things that you can do in that regard is to use multi-factor authentication. I do this, and have done for some time. Unfortunately, SharePoint Online doesn’t support multi-factor authentication.

Normally this isn’t a big problem, you can just register and supply an application password. Skype for Business still requires this as an example. Unfortunately PowerShell does not allow application passwords. There is no way around this problem.

I fortunately had access to an administrator account that does not use MFA, and I was able to provide that to connect successfully. If you do not, you’ll need to create one in your Office 365 tenant to do this.

3. Set the storage quota

The final step is to run the PowerShell command that actually sets your quota. The syntax of this command is:

Set-SPOSite -Identity https://yourmysiteurl -StorageQuota 5242880

The –Identity parameter is the URL of your MySite, which is where OneDrive is stored. the format usually incorporates your company’s normal SharePoint URL, adds a –my and your email, slightly altered. Therefore if your company name is “CoolCompany” and your email address is “joe@coolcompany.com”, then your MySite url is  https://coolcompany-my.sharepoint.com/personal/joe_coolcompany_com .

Finally, the –StorageQuota parameter needs to be 5242880 which corresponds with 5TB. I assume that you double it for 10 TB, but I haven’t been able to test that, as I haven’t uploaded enough to qualify for the next tier. You can only request storage increases in 5 TB chunks.

Once the quota has been successfully set, you should be able to see your new cap in the OneDrive for Business web UI. Just hover over the OneDrive for Business icon in your tray, right click and select manage storage.

image

The storage Metrics page will open and your storage allocation can be found in the upper right.

image

It’s not easy, but it’s worth it if you have a qualifying account.

Troubleshooting and Removing a Failed Installation or Upgrade of PowerPivot for SharePoint

I recently had the opportunity to perform an upgrade of PowerPivot from SQL Server 2008 R2 to SQL Server 2012 for a customer with a relatively large SharePoint farm. Their farm consisted of 4 SharePoint front end servers, 2 SharePoint application servers, and a SQL Server 2008 R2 cluster. The PowerPivot for SharePoint 2008 R2 service was installed on the 2 application servers. The upgrade didn’t go quite as smoothly as planned and in the process it was necessary to manually remove all traces of the PowerPivot 2008 R2 service. This was a little tricky (to say the least), so I thought that I’d share the experience here in hopes that it helps someone.

The original plan was to remove the PowerPivot service from the second server, then perform a SQL server upgrade on the remaining server, upgrading the PowerPivot for SharePoint instance. The PowerPivot configuration tool would then be run on the single server, upgrading the SharePoint elements. Finally, PowerPivot for SharePoint 2012 would be reinstalled on the second application server.

This is an approach that has worked quite well in the past, but in this particular environment, the configuration tool could not run the upgrade process. Due to the fact that there had been no work done on scheduling data refreshes thus far, it was decided that a complete removal, and install from scratch was in order. This is where things got particularly tricky. The configuration tool was unable to run its uninstall process, so I elected to remove everything manually, which consisted of deactivating the PowerPivot features in the destination site collections and from Central Admin, then retracting the PowerPivot solutions from Farm Solutions. Finally, SQL Server installation was run, and the PowerPivot instance removed from the server completely.

Removing PowerPivot Breaks Central Administration

At this point, Central Administration became unavailable. A quick search through the ULS logs for the correlation ID reported that there were errors loading the Microsoft.AnalysisServices.SharePoint.Integration assembly. As a next step, I ran through the SharePoint Configuration Wizard (psconfigui) to make sure that everything was OK. As it turns out, it wasn’t OK, and the wizard repeatedly failed.

image

After some searching, I located a TechNet article that pointed out the problem. Apparently with 2008 R2, PowerPivot has a little trouble uninstalling itself, and leaves a few artefacts. Two of the artefacts are the registry keys listed in the article, and when the configuration wizard sees them, it tries to load the assembly, which of course no longer exists, and then it fails out. Removing the two keys fixes this particular problem, and I’m reproducing the steps for doing so below for convenience.

Open the registry editor. To do this, type regedit in the Run command.
Expand HKEY_LOCAL_MACHINE
Expand SOFTWARE
Expand Microsoft
Expand Shared Tools
Expand Web Server Extensions
Expand 14.0
Expand WSS
Expand ServiceProxies
Right-click Microsoft.AnalysisServices.Sharepoint.Integration.MidTierServiceProxy and select Delete.
Go back a step in the hierarchy. Under WSS, expand Services
Right-click Microsoft.AnalysisServices.Sharepoint.Integration.MidTierServicea and select Delete.

After getting rid of the registry entries, the configuration wizard completed successfully, and more importantly, Central Administration loaded up properly. In addition, to this, I also removed the same registry keys from the second application server in anticipation of a reinstall.

It was therefore time to reinstall PowerPivot. Installation from the SQL server media went fine (don’t forget to add all necessary accounts as administrators, particularly the account that is running the Analysis Services Windows service).

Parent Service Does Not Exist

However, re-running the PowerPivot configuration Tool resulted in the error “Cannot create the service instance because the parent Service does not exist”.  

image

This turned out to be a particularly vexing problem. The only guidance that I could find in the forums was incorrect (things like, “the Database engine must be installed with the PowerPivot instance”, which is patently false). I went to the source PowerShell scripts that register the service, and was able to run them, and register the service. The PowerPivot service then appeared under Services on Server, and I was even able to create a new PowerPivot service application thorough the Central Administration UI. However, attempting to access it resulted in an error (which I no longer have access to). Examining the ULS logs showed “access denied” attempting to connect to the Analysis Services instance.

In addition, subsequent attempts to run the PowerPivot configuration tool resulted in a perplexing error that stated that all servers in the farm must be running the same service account, and that they should all be changed to run as LOCAL SERVICE. This is particularly odd given that PowerPivot MUST be installed with a domain account, so this isn’t even possible.  As it turned out, this was a red herring, and occurred because I had incorrectly specified the credentials of the service account in my PowerShell scripts from above, and it had provisioned using the LOCAL SERVICE account. I was able to change the identity of the service through Central Administration in the Security section, by configuring the service accounts, and then the PowerPivot configuration tool was able to run to completion. However, the service application, and its proxy appeared as stopped in the Service Applications list.

Manual Uninstallation

Something was still amiss, and for the life of me I couldn’t figure out what it was. At this point, I engaged the PowerPivot support team. After eliminating a few other potential issues, we decided to manually uninstall PowerPivot and use a few clean-up tools afterward. I again deleted service applications, deactivated features, retracted and removed solutions, and uninstalled PowerPivot for SharePoint with the SQL Setup application. Once everything had been theoretically removed, I ran this PowerShell script (repeated below) provided by the Support team to force the removal of all remaining PowerPivot items from the farm.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction:SilentlyContinue

Function DeleteServiceAndInstances
{
    param($service)
    if($service)
    {
        foreach($instance in $service.Instances)
        {
            $instance.Delete()
        }
 
        $service.Delete()
    }
}

Function DeleteServiceApplications
{
    param($service)
    if($service)
    {
        foreach($instance in $service.Applications)
        {
            $instance.Delete()
        }
    }
}

Function DeleteServiceApplicationProxies
{
    param($proxy)
    if($proxy)
    {
        foreach($instance in $proxy.ApplicationProxies)
        {
            $instance.Delete()
        }
    }
}

Function DeletePowerPivotEngineServiceAndInstances
{
    $farm = Get-SPFarm
    $service = $farm.Services | where {$_.GetType().GUID -eq "324A283C-6525-43c8-806C-31D8C92D15B7"}
    DeleteServiceAndInstances $service
}

Function DeletePowerPivotMidTierServiceAndInstances
{
    $farm = Get-SPFarm
    $service = $farm.Services | where {$_.GetType().GUID -eq "35F084BE-5ED5-4735-ADAA-6DB08C03EF26"}
    foreach($job in $service.JobDefinitions)
    {
        $job.Delete()
    }

    DeleteServiceApplications $service    
    DeleteServiceAndInstances $service
}

Function DeletePowerPivotEngineServiceProxy
{
    $farm = Get-SPFarm
    $proxy = $farm.ServiceProxies | where {$_.TypeName -eq "Microsoft.AnalysisServices.SharePoint.Integration.EngineServiceProxy"}
    if ($proxy)
    {
        $proxy.Delete()
    }
}

Function DeletePowerPivotMidTierServiceProxy
{
    $farm = Get-SPFarm
    $proxy = $farm.ServiceProxies | where {$_.TypeName -eq "Microsoft.AnalysisServices.SharePoint.Integration.MidTierServiceProxy"}
    if ($proxy)
    {
        DeleteServiceApplicationProxies $proxy
        $proxy.Delete()
    }
}


DeletePowerPivotEngineServiceProxy
DeletePowerPivotMidTierServiceProxy
DeletePowerPivotEngineServiceAndInstances
DeletePowerPivotMidTierServiceAndInstances

This script ran successfully, and in theory should have removed all of the PowerPivot elements from the SharePoint farm. However, just to be sure, we ran the following SQL script (also provided by MS support) to look for any orphaned PowerPivot elements in the farm configuration database:

   SELECT Id, classid, parentid, name, status, version, properties
   FROM objects
   WHERE name like '%PowerPivot%'
   ORDER BY name

Lo and behold, there was still a record in the configuration database pointing to an instance that obviously no longer existed. Now, direct editing of the configuration databases is not something that anyone should do lightly, and it’s not generally supported. However, in a few cases, it’s the only option, and according to support, this was one of those cases. I therefore took a backup (ALWAYS take a backup first!) of the config database, and then ran the following SQL query to determine if the instance had any configuration dependencies.

SELECT * FROM Objects (NOLOCK) WHERE Properties LIKE ‘%GUID-found-in-earlier-query%'

The GUID is the value of the ID field found in the previous query for the orphaned item. In my case, there were no items returned, but if there were, the dependencies would need to be removed. If you find dependencies, you will need to contact support yourself, as there are additional complicating factors involved that will need to be evaluated by the product group.

Since I had no dependencies, I was safely able to delete the offending record.

   DELETE FROM objects WHERE name like '%PowerPivot%'

My Configuration Database was now clean.

The Return of the Parent Service Error

At this point, I reinstalled PowerPivot for SharePoint, and once again, ran the PowerPivot configuration tool. Unfortunately, I ran right into the “Parent Service Does Not Exist” error discussed above. This was frustrating, to say the least. After several choice words, and some sleep, I decided to do yet another uninstall/reinstall. This difference this time is that instead of retracting solutions manually, I would allow the configuration tool to do the uninstall for me. When I did, it generated an error when it attempted to uninstall a feature:

The feature with ID ‘1a33a234-b4a4-4fc6-96c2-8bdb56388bd5’ is still activated within this farm or stand alone installation. Deactivate this feature in the various locations where it is activated or use -force to force uninstallation of this feature.

This GUID is the PowerPivotSite feature, which was still activated at one of the site collections. I then used stsadm to force the uninstallation of the feature (I used stsadm simply because I’m a dinosaur, and know the switches off the top of my head. Obviously PowerShell would work just a well, if not better).

stsadm -o uninstallfeature -id ‘1a33a234-b4a4-4fc6-96c2-8bdb56388bd5’ -force

After forcibly removing the feature, I used the PowerPivot configuration tool to remove PowerPivot. Once removed, I ran it again to configure the PowerPivot instance, and this time, it completed successfully.

I did note one thing that I thought was odd, and haven’t been able to explain. On this last run of the configuration tool, the step that provisioned the PowerPivot service application took an inordinately long amount of time, about an hour. Not content to leave well enough alone, I deleted the service application, and re-ran the tool. This time it completed in under a minute. I only mention this in case someone tries this and gives up because they think the system has hung up.

Once I got the first server up and running, it was relatively simple to install PowerPivot for SharePoint 2012 on the second application server, and run the configuration tool, which did everything necessary to add the second application server back into the PowerPivot rotation.

After cleaning up the remaining configuration items common to PowerPivot for SharePoint, and cleaning up the Health Analyzer errors, PowerPivot now appears to be running smoothly on this farm.

Opening PDF Files in SharePoint 2010

If you’ve installed SharePoint 2010, you may have noticed a change in behaviour of any PDF files that you may have stored. Previously, they would open directly in the browser, but now the user is prompted to save the file to the disk. This is due to a new security feature in IE8 that SharePoint 2010 respects. In order to allow the old behaviour, you must set the browser file handling options to “permissive” as opposed to “strict”.

This change is done at the application level. First, navigate to Manage Web Application within Central Admin, select the application in question, and choose General Settings on the ribbon.

image

Once in the settings screen, scroll down and find the section for Browser File Handling, and change it to permissive.

image

It goes without saying that this is less secure, but if you trust your PDF files, you should be good to go. Of course,as always,no warranties, express or implied…

Thanks to Mike Hacker’s Blog where I originally came across this.

UPDATE – SEPT 7 2010

I just ran across a case where this does not fix the problem. PDFs and all file types including HTML were prompting the user for download. This was not consistent, as it was happening in some libraries and not others. As it turns out, it’s a bit of a bug, and document libraries will not always inherit the browser handling attribute.

You can test this by running the following Powershell:

$site = Get-SPSite(“https://mysitecollection")
$web = $site.OpenWeb("/MyWeb")
$list = $web.GetList("https://myweburl/LibraryName")
$list.browserfilehandling
If it returns “Strict”, then you have a problem. The good news is, you can set it:
 
$list.browserfilehandling = “Permissive” ;
$list.update();
You should probably loop through your entire site collection and set this value to be safe. The powershell to do this can be found  on Nerdtastics Tips, which is where I found the fix in the first place.

 

UPDATE – SEPT 10 2010

As opposed to hunting through your sites to find the problems, I wrote the below PowerShell script that take the URL for the site collection as an argument, and sets the permissive flag on any lists set to strict.

Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
$siteURL = $args[0]
$webname = $args[1]
$site = Get-SPSite($siteURL)

foreach ($web in $site.AllWebs) {
    Write-Host "Inspecting " $web.Title
    foreach ($list in $web.Lists) {
        if($list.browserfilehandling -eq "Strict") {
            Write-Host "Changing " $list.Title
            $list.browserfilehandling = "Permissive";
            $list.update();
            $site.url,
            $list.title,
            $list.browserfilehandling
        }
    }
}

UPDATE – OCT 5 2010

I’ve run into more situations where this doesn’t solve the problem. I created a new post describing them here.