Contents tagged with Office Web Apps
-
SharePoint 2013: Enabling PDF Previews in Document Libraries with Office Web Apps 2013
Introduction
A couple of weeks back I blogged about the March Update for Office Web Apps 2013 and also how you could use that update to show PDF previews in a SharePoint 2013 Search Center. Since then I’ve received a lot of requests on how to enable PDF Previews in a Document Library, which isn’t there by default. Of course it is not a WAC thing, it’s a SharePoint 2013 thing – but the SharePoint 2013 updates (up until now at least) does not provide this capability either.
In this post I will show you that it can be done. It’s a JavaScript thing and can be done using a Content Editor Web Part added on all pages where you want the PDF previews or as Farm solution which uses a delegate control and a custom JavaScript file.
Build the PDF Preview solution
I assume that you are familiar with SharePoint 2013 development and knows what a delegate control is. What you need to do is create a new empty Farm solution project. In this project we’ll create a new web control that will add a JavaScript (which we will create in just a minute) to the page. The implementation should look like below:
[MdsCompliant(true)] public class PdfPreviewControl: WebControl { protected override void OnPreRender(EventArgs e) { ScriptLink.RegisterScriptAfterUI(this.Page, "wictor.pdfpreviews/previews.js", false); } }The JavaScript file, added as a Layouts file, is what makes the magic happen. We’re using the Script-On-Demand features in this script to make sure that the scripts aren’t executed before the SharePoint filepreview.js file is loaded. Once that file is loaded two new JavaScript objects are created; the filePreviewManager and the embeddedWACPreview. To enable the PDF previews we only need to add the PDF extension to these objects and specify the previewer objects and the dimensions. In this case I use the same settings as the other Word previewers.
function WictorsPdfPreviews() { SP.SOD.executeOrDelayUntilScriptLoaded(function () { filePreviewManager.previewers.extensionToPreviewerMap.pdf = [embeddedWACPreview, WACImagePreview]; embeddedWACPreview.dimensions.pdf= { width: 379, height: 252} }, "filepreview.js"); notifyScriptsLoadedAndExecuteWaitingJobs("wictor.pdfpreviews/previews.js"); } WictorsPdfPreviews();Now we need to make sure that this control loads the JavaScript on all pages. This is done by adding a new Empty Element SPI and creating a Control element pointing to the web control, like this:
<Control ControlAssembly="$SharePoint.Project.AssemblyFullName$" ControlClass="Wictor.PdfPreviews.PdfPreviewControl" Id="AdditionalPageHead" Sequence="100"/>
As you can see we’re adding this control to the AdditionalPageHead, which means that we will have it on every page. Do not forget to add the web control as a Safe Control in the project!
The final thing we need to do is to modify the Feature that was automatically created when the Empty Element SPI was added to the project. You can scope it to whatever you like, but I want it for all Document Libraries in my farm so I set the scope to Farm. The image below shows all the files in the project.
Deploy and Test
Now all we have to do is to deploy the solution. Once the solution is deployed and the Farm feature activated we can navigate to any document library and upload a PDF file. Note that you have to be on at least the March 2013 update of Office Web Apps Server and that you have enabled the WordPDF application (see previous blog post). Once you have the PDF file in the library you can click on the ellipsis button and see the PDF Preview:
Disclaimer
As always when it comes to stuff that is not documented. I do not give any guarantee that this will work on your machine(s) or after any upcoming SharePoint patches.
Summary
Enabling PDF Previews are not (yet) a default feature of SharePoint 2013 but can easily be added to your SharePoint farm – if you’re allowed to use Full Trust solutions. If you don’t feel like you want to do some hacking yourself you can download the WSP here and deploy it yourself to try it out.
-
Introducing Open WOPI - an open WOPI Client for SharePoint, Exchange and Lync
Today at the SharePoint Evolutions 2013 Conference I announced my latest pet project called Open WOPI. Open WOPI is an open WOPI client that allows you to extend SharePoint 2013, Exchange 2013 and Lync 2013 with file previews and editors for any type of file formats.
The project is now (at least very, very soon) available to download from openwopi.codeplex.com and is published under the Ms-PL license. This is currently an early beta (or what you would like to call it) but will be improved over time.
Standards
Open WOPI is based on the [MS-WOP] protocol, published by Microsoft, and used by Office Web Apps Server 2013, SharePoint 2013, Exchange 2013 and Lync 2013.
File format support
Currently Open WOPI has support for the following formats:
- GPX - Uses Bing maps
- TXT - Viewing and editing
- VSDX - Thumbnail viewing
More formats are in the works…
Documentation
Not much yet, but I’ll try to add that over the next few weeks.
More information
For more information, feedback and ideas about the project please refer to the Codeplex site: openwopi.codeplex.com. I’d like to hear what file formats you would like Open WOPI to support.
The slides from the presentation at the SharePoint Evolutions conference and links can be found here.
Contributors
Thanks to Sam Dolan, aka Pinkpetrol, for the really cool logo for Open WOPI.
-
SharePoint 2013: Enabling PDF Previews with Office Web Apps 2013 March 2013 update
In my last post (still smoking fresh) I showed you how to update your Office Web Apps 2013 farm to the March 2013 update, connect it to SharePoint 2013 and being able to view PDF documents in the browser. What I didn’t explain or show in that post was how to enable the PDF Previews in Search – but I’ll do it now.
Pre-requisites
Before you start fiddling with this, you need to make sure that you have the March 2013 update of Office Web Apps Server 2013 (WAC) installed and connected to your farm – if you don’t know for sure, ask your admins – sometimes they know…if they don’t give them the link to my previous blog post.
Note: You don’t have to have a patched SharePoint 2013, this will work on the RTM bits.
Default PDF Search Experience
SharePoint 2013 natively supports crawling PDF documents, through the new document parsers. That is you don’t have to fiddle with any custom PDF IFilters etc. The native PDF document parser is a good enough solution, but have some room for improvements.
The Search Experience and display in SharePoint 2013 is based upon Display Templates. Display Templates decide how the result should be shown and how the fly-out of the result should look like. For Office documents, when SharePoint 2013 is connected to a WAC farm, SharePoint displays inline previews which you can use to skim through the results really quick. For PDF this is not the case – not even if you use a WAC farm with the March 2013 update (even though the WOPI binding supports the interactivepreview action). This is a sample on how a PDF document could look like in SharePoint 2013 Search:
Enabling PDF Previews in the Search Result
Since we have the opportunity to modify the Display Templates and create our own Search Experience we can very easy modify the fly-out/hover panel of the PDF results to show the interactive preview. We can do this in two different ways…
Create a new Result Type
The easiest and fastest approach to enable our previews for PDF documents is by creating a custom Result Type. This is done by going to Site Settings > (Search) Result Types and then finding the PDF Result Type. Choose to Copy the Word Result Type. This will create a new Result Type.
Give the new Result Type an appropriate name, “PDF with Preview” for instance. Then scroll down to Actions and in the “What should these results look like?” drop-down, choose to use the Word Display Template.
Then just click Save, go back to your Search Center and search for a PDF document and voilá – we have PDF Previews.
Modifying the PDF Display Templates
The second approach, which is a bit more advanced is to actually modify the PDF Flyout Design Template. You do this by going to Site Settings > Design Manager then choose 5. Edit Display Templates. Locate the PDF Flyout item by filtering on the Target Control Type column and use SearchHoverPanel, then scroll down to PDF Hover Panel. To modify the PDF Hover Panel, use the Word Hover Panel as a template. I’m not going in to all the details on how to modify the actual HTML file (see my similar post on how to achieve this here). But once you’ve modified it, make sure to save it to the gallery so the JS file is generated, and publish it. Now (if you made the correct updates) you will have Custom Search Previews for PDF documents.
Summary
You’ve now seen how you quick and easy can enable PDF Search Previews in SharePoint 2013 using the March 2013 update for Office Web Apps 2013. All you need to do is either create a custom Result Type and use the Word Display Templates or modify the default PDF Display Template. I really hope that Microsoft makes this a standard feature for upcoming SharePoint 2013 releases.
-
Office Web Apps 2013: Patching your WAC farm with no downtime
I’m really glad to see some patches being rolled out for Office 2013, SharePoint 2013 and Office Web Apps 2013. There’s some really important fixes and some very interesting fixes that I’ve been waiting for. In this post we’ll take a look at the first Office Web Apps 2013 (WAC) update – specifically we’re looking at how to patch your WAC farm to minimize the downtime. If you follow my instructions you will have zero downtime (except for a brief moment where Excel stuff will not be accessible).
Background and preparations
For this sample I will have a SharePoint 2013 (RTM) farm connected to a WAC 2013 (RTM) farm. The WAC farm is load balanced using NLB, like illustrated on the right. On order to update our WAC farm we need to download the March 2013 patch for Office Web Apps 2013. You can find it at Microsoft Download center and it is called “Update for Microsoft Office Web Apps Server 2013 (KB2760445)”. The KB article does not reveal much of what has changed, but if you take a look at an earlier patch KB2760486 (March 5th) you’ll notice some really cool things. If you don’t have time to read it – I’ll show you some of them at the end of this post. Ok, you do not have to install KB2760486, you only need the KB2760445 one.
Patching the first WAC Server
After downloading the patch and copying it to our WAC machines we can start the patching process. We would like to do this without the users even noticing it. First of all we need to take one of the servers out of rotation in the WAC farm. You do this using the load balancer. In my case I’m using Microsoft NLB and using PowerShell this is an easy task. Next thing to do is just remove the WAC server from the WAC farm – that is also a one-line PowerShell command. WAC Servers should only be patched with the binaries installed, not when they are participating in a WAC farm.
These two lines does the trick:
Get-NlbClusterNode -NodeName $env:COMPUTERNAME | Stop-NlbClusterNode -Drain Remove-OfficeWebAppsMachine
NOTE: You MUST remove the machines from the old farm before patching and then later create a new WAC farm (follow the instructions thoroughly). You cannot patch a running WAC Farm!
Once this is done the server is no longer receiving requests and it’s no longer a part of the WAC farm and we can start patching this machine. All our end-user requests are now going to the remaining server(s) in the WAC farm.
To patch the machine start the downloaded .exe file (wacserver2013-kb2760445-fullfile-x64-glb.exe) and just follow the instructions; accept license agreement etc. You will be asked to close any PowerShell (IDE) windows that has the Office Web Apps module loaded and you might get asked to reboot once the update is finished (there’s of course no harm in doing it anyways).
When the patching is done (and you rebooted) we need to create a new WAC farm, on the patched server. You do this using the same way as you did for the RTM version. Use the same server name as your old farm, same settings and the same certificate.
Patching the rest…
Once the new farm is created you have a few options depending on how many servers you have in your WAC farm. For instance if you have more than two, then you can take another one out of rotation, patch it and join it to the new and patched farm and then you flip the load balancer so it points to the new WAC farm. Depending on your load balancer you might have a brief moment where end-user request might be served by both versions. A bit funky situation but it works, as the illustration below shows:
In my case I have two servers, so once I created the new farm I just put the patched server into the NLB rotation and then immediately take the RTM server out of rotation. Once the RTM WAC Server is taken out of rotation I remove WAC from that machine and start the patching process. All requests to the WAC farm are now on our patched server(s).
As you can see, simple PowerShell operations this time as well, and this can (and should) be automated.
# On the new patched WAC Server Get-NlbClusterNode -NodeName $env:COMPUTERNAME | Start-NlbClusterNode # On the RTM WAC Server Get-NlbClusterNode -NodeName $env:COMPUTERNAME | Stop-NlbClusterNode -Drain Remove-OfficeWebAppsMachine
Once the other server(s) are patched, you need to join it to the newly created (and patched) WAC farm – just as you normally join a server to a WAC farm. And then you’re done. You’re farm is now patched and ready! But wait, there’s some stuff you have to do on the SharePoint side to enjoy all the new cool features.
Configuring new WOPI bindings
One of the most interesting new features in the March 2013 update of Office Web Apps is the ability to view PDF documents! Yup, you heard me right! The March 2013 update contains a couple of new WOPI bindings that enable viewing and previewing (even mobile views) for PDF documents. These new WOPI binding has an application name called WordPdf. If you try to use the New-SPWOPIBinding cmdlet and just specify the WAC server name, you will get an error – since you already have those WOPI bindings. What you need to do is to specify the name of the application as an extra parameter to the command, like this:
New-SPWOPIBinding - ServerName wac.corp.local -Application WordPdf
Another approach could be to remove all the bindings and then add them all back again – of course this would cause a few seconds of downtime, and that’s not how I roll…
Once you’ve run that command (and waited a couple of seconds) you can start previewing PDF documents in your Document Libraries. And now we got yet another good reason not to install the crapware called Adobe Reader!
Now, your end users can start taking advantage of all the new features in the March 2013 update.
New Excel WOPI Bindings!
If you’re examining the WOPI bindings provided by the March 2013 update really carefully, you’ll notice that the Excel application has six new bindings, three each for the two new actions syndicate and legacywebservice. We cannot use these two bindings in SharePoint 2013 RTM – the New-SPWOPIBinding cmdlet does not accept those actions. They are not a part of the well-known WOPI action values (as specified in the WOPI specification available when this post is written) – and I have at the moment no clue of what they are doing…stay tuned…
Summary
You’ve just seen how simple patching an Office Web Apps 2013 farm is. Compare that to patching SharePoint! By using the load balancer effectively you can make sure that the end-users can continue to use the Office Web Apps features while you’re doing the patching. Enjoy!
-
Office Web Apps 2013: Securing your WAC farm
With this new wave of SharePoint, the Office Web Apps Server (WAC – I don’t like the OWA acronym, that’s something else in my opinion) is its own server product, implementing the WOPI client protocol, which allows a client to retrieve documents from SharePoint on the behalf of the user. Documents will flow from the WOPI servers (SharePoint, Lync, Exchange etc.) to the Office Web Apps Server – this means that potentially confidential information will be transferred from the SharePoint environment and stored/cached on another server. This could result in unnecessary information leakage and compromise the enterprise security.
In this post I will walk through a number of steps that you can do to properly secure your Office Web Apps 2013 farms. And you should seriously consider and implement most of these methods.
Note: this post focuses on the Office Web Apps Server and not a WOPI client in general (but if you’re building your own you should consider security as well!).
The WOPI protocol specification and security
Note: I will not cover how WOPI clients and servers implements the server to server authentication and authorization.
WAC runs as Local System
To start with it is very important to know that the Office Web Apps Server 2013 runs as the Local System and Network Service on the machine it is installed on. There is no service account or anything! This means that you cannot protect your systems using dedicated accounts etc., like you do with SharePoint, SQL and other applications.
The images below shows the Office Web Apps Windows Service, which runs as LocalSystem.
And this image shows some of the applications pools in the IIS on an Office Web Apps machine.
The advantage of using these local accounts is that it makes installation and configuration easier. But it is very important that you are aware of this configuration.
SSL is a requirement!
Exposing the Office Web Apps Server over HTTPS should be a requirement in my opinion. There is no reason not to. Having it on HTTP will only cause trouble for you; for instance if your SharePoint uses https you will not be able to render the iFrame containing the document (aka WOPI Frame) since you’re not allowed to show http content in an https environment. But first and foremost you’re sending data in clear text.
So what about SharePoint on HTTP then? Well, if you’re using SharePoint 2013 you should seriously consider running that over HTTPS as well – that IS a best practice. SharePoint 2013 leverages several technologies that sends tokens and credentials over the wire, OAuth for instance, so in order to have a secure environment make sure you use HTTPS for SharePoint as well. If you are running SharePoint on HTTP you must fiddle with the security settings in SharePoint to allow OAuth over HTTP – and this is not a good thing.
Certificates are king!
Any WAC farm running on SSL must have a certificate for the HTTPS endpoint. You can use self-signed, issue certificates using a Domain CA or buy a certificate. When you’re creating the WAC farm, using New-OfficeWebAppsFarm, you can/should specify the certificate.
For any SharePoint, WAC and even SQL installations nowadays certificates are more and more important. If you’re on the verge of deploying these in your organization you should consider deploying a Domain CA – which is not a lightweight task.
Securing the communication using IPSec
If you for some reason do not run HTTPS on SharePoint and/or WAC you could consider implementing IPSec. Unfortunately there is no button in the Control Panel that says “Use IPSec”. This is something that requires careful planning and testing. So going SSL might be an easier way. But consider the scenario where you have an internet facing web site which leverages WAC and using the HTTP protocol – then you should consider using IPSec for the communication between SharePoint and Office Web Apps Server.
Firewall considerations and requirements
When setting up your Office Web Apps Farm you should also configure the firewall for the WAC machines. Office Web Apps uses four different ports. It uses 80 and 443 for HTTP and HTTPS, that’s used by the end-users and the WOPI Server/Client communication. Internally Office Web Apps uses port 809 (HTTP) and 810(HTTPS) for communication between the WAC machines. I’ve only seen 809 in use, which is the default. There is no way (I’ve found at least, but internally WAC has a switch to use port 810) to configure WAC to use port 810 and if you do find a way, it’s likely unsupported. The things sent over the wire using the admin channel (809) is mainly health and configuration information for the WAC farm, but it would be nice to be able to secure this channel as well (IPSec!).
When installing WAC the Windows firewall is configured to allow incoming TCP connections on port 80, 443 and 809.
As always it is a good practice to evaluate these default rules and if you’re not using port 80, disable that port. For port 809 it might also be a good practice to make sure that it only allows incoming connections if they are secure (i.e. implement IPsec).
Preventing rogue machines
So far we’ve been talking about how to secure information being transmitted from and to the Office Web Apps farm. Let’s take a look at Office Web Apps farm security from another angle. Joining a new WAC machine to an Office Web Apps Farm can be quite easy. The only thing that you need is local administrator access on the WAC machine that is the master (the
Get-OfficeWebAppsMachinegives you the master machine). Depending on how you’re having your (virtual) metal hosted this might be a problem, too many sysadmins have to much permissions out there. If you have this access then you can easily join a rogue machine to the WAC farm and take control over it, without the users/client knowing anything about it.There are a couple of methods you can and should use to protect the WAC farm. And the error messages below can also be a good troubleshooting reference…
Master Machine Local Administrator
If the account trying to create the new WAC machine does not have local admin access on the machine specified when joining the WAC farm you will simply get an “Access is denied”.
As a side note; if you’re not running the cmdlet using elevated privileges you will get an “You must be authenticated as a machine administrator in order to manage Office Web Apps Server”.
Using the Firewall
I already mentioned the firewall. If the machine joining the WAC farm cannot access the HTTP 809 channel the New-OfficeWebAppsMachine will throw a “The destination is unreachable error”.
This is a fairly easy way to protect the farm, but if the user has local admin access on the master machine it can easily be circumvented.
Certificate permissions
If you’re using a domain CA, make sure that you protect the private key using ACL’s, or if you’re buying a certificate make sure to store the certificate private key in a secure location. If you’ve specified a certificate when the Office Web Apps farm was created, which you should have, then the user cannot join the new machine – regardless of local machine admin, since the user cannot install the certificate locally. The error message shown is “Office Web Apps was unable to find the specified certificate”.
Using an Organizational Unit in Active Directory
The way that Microsoft recommends to secure your WAC farm is to have a dedicated OU in Active Directory where the computer accounts for the WAC farm is located. When joining a new machine to the farm the cmdlet verifies that the account is in the OU specified by the WAC configuration. If it’s not then you’ll see the “The current machine is not a member of the FarmOU”.
The Farm OU is specified when creating a new WAC farm or using the
Set-OfficeWebAppsFarm/cmdlet. The only caveat with this OU is that it has to be a top level OU in Active Directory. Creating that OU in your or your customers AD might cause some headache, but if you want to use theFarmOUas protection method for your farm it has to be this way. That’s the way it is designed!Also having all the WAC servers in a OU gives you other benefits; such as using Group Policies to control the WAC servers.
Limit the WOPI Server and host access
Now we’ve seen how we protect the farm from rogue machines and data tampering. Another issue with the WAC farm in it’s default configuration is that any WOPI Server can use it. Might not be a big problem for most of the internal installations, but what if you’ve designed a WAC farm and someone with a huge SharePoint collaboration implementation connects to your WAC farm. It can sure bring it down. Or if you’re exposing your Office Web Apps farm on the internet anyone on the internet can potentially use it.
For this purpose there’s a cmdlet called
New-OfficeWebAppsHost. This cmdlet allows you to specify host names that will be accepted by the WAC farm. The cmdlet interprets any domain with a wildcard. For instance the following cmdlet will allow all WOPI Servers on contoso.com (www.contoso.com, extranet.contoso.com etc.) to contact the WAC farm:Set-OfficeWebAppsHost -Domain "contoso.com"
Do not forget to do this!!
Summary
You’ve seen quite a few ways how to protect your WAC farm from information leakage, rogue machines, undesired excessive usage etc. Using HTTPS and certificates together with a dedicated OU in Active Directory will give you the most secured WAC Farm. Hopefully you also understand a bit more on how Office Web Apps Server works internally. It’s a magnificent and simple server product, but it should be handled with care.
