Tag: Office Web Applications

How to Use a Wildcard Certificate With Office Web Apps 2013

Published October 7, 2014

There is a lot of guidance out there that indicates that it isn’t possible to use wildcard certificates with Office Web Apps 2013. Much of this stems from one of the certificate requirements listed in this Technet document:

“The FQDN in the SAN field can’t begin with an asterisk (*).”

On first blush, this would in fact rule out wildcard certificated since their SAN (Subject Alt Name) or friendly name is the FQDN of the wildcard (*.domain.com). Indeed, there is no way in the IIS manager to alter the name of the certificate . Issuing a PowerShell command the create a new Office Web Apps server farm with the wildcard name results in the certificate being invisible to the command, and you receive the following error:

However, in my experience, wildcard certificates work just fine with Office web apps. There is just a trick to getting them to work.

The problem isn’t the wildcard certificate per se, it’s the fact that the friendly name can’t contain a wildcard. All that we really need to do is to change it. It’s not immediately obvious how that’s done, but it can be done through the MMC snap in.

If the certificate is already on the server, then great, but if not, you’ll need to import it. In this example, we’re importing a certificate that’s been exported from another server, a common enough scenario for wildcard certificates. However, the origin doesn’t matter.

The first thing you’ll need to do is to run MMC (Microsoft Management Console). To do this, from a command prompt, type MMC and hit enter. Then load the Certificates snap in, selecting the Local Computer store when prompted.

The location of the certificate is important. If it’s not in the right place, the new farm command won’t see it, and you’ll receive exactly the same error as above. The certificate needs to be imported into the Personal folder of Local Computer. Right click on the Certificates folder, hover over All Tasks, and select Import. Then, go through the prompts and select the certificate to import.

Once imported, we want to change its Friendly Name. We can do that by selecting the certificate, right clicking it, and selecting Properties.

From here, it’s a simple matter of changing the friendly name from the wildcard address, to something with significantly fewer asterisks, in our case xxxxxxwildcard

Once done, click OK, and close the MMC. Your certificate now has a friendly name that you can use to create your Office Web Apps farm.

New-OfficeWebAppsFarm -InternalUrl "https://xxx.xxxxxxxx.com" -ExternalUrl "https://xxx.xxxxxxxx.com" -CertificateName "xxxxxxWildcard" –EditingEnabled

Once created, you can continue to configure your Office Web Apps farm, and then bind SharePoint to it.

While I’m on the topic, and because it comes up frequently, once you have bound your SharePoint farm to the Office Web Apps server, it’s important to turn off view rendering for Excel files if your farm uses Excel Services. This is because the Office web apps don’t support data connections in Excel files, or PowerPivot models, and data interactivity won’t work. By issuing the following command:

New-SPWOPISuppressionSetting -extension xlsx -action view

we tell the SharePoint farm to use Excel Services (which supports data connections) when viewing xlsx files, not Office Web Apps.

Finally, if this is being added to an existing farm, you’ll want to run a full crawl to repopulate your search index with the new rendering mechanism for Office documents.

14 Comments

Office Web Applications In SharePoint 2013 – Bigger, Faster, Better?

Published July 23, 2012

At the same time that SharePoint 2010 was released, the Office team released the Office Web Applications. These browser versions of Word, Excel, and PowerPoint were tightly integrated with SharePoint and in fact originally required SharePoint to run. To install them, you would stand up a SharePoint server, and then install the web application bits on that server. Like a service pack or CU, you would then run PSCONFIGUI to integrate the bits into the farm, and install the relevant service applications. Simple enough.

However, there were some quirks associated with them. As noted here, removing the web applications from the server would actually remove the server from the farm. Simple enough to correct, but if you uninstalled the SharePoint bits before uninstalling the Office Web Application bits, you could be left with an effectively inoperable server.

During the 2010 release lifetime however, we started to see the Office Web Applications pop up elsewhere. Initially powering Facebook’s docs.com, they could also be seen as part of Windows Live. Obviously, when Office 365 was released, they were front and center. With this increasingly broad adoption, and requirement for scale, a reliance on SharePoint as a platform made less and less sense, and now, for 2013, we get a new architecture.

Standalone Web Applications Server

The big change is that Office Web Applications is no longer reliant on SharePoint. It installs and configures independently and it can serve any number of clients, SharePoint being one, and Exchange being another. In fact, it’s now positively hostile to SharePoint and other servers – you can’t install it on a machine where the SharePoint bits are installed at all. The same goes for Exchange, Lync, SQL Server, or anything really. The following is from the TechNet document “Plan Office Web Apps Server Preview”:

Servers that run Office Web Apps Server Preview must not run any other server application. This includes Exchange Server, SharePoint Server, Lync Server, and SQL Server. If you have hardware constraints, you can run Office Web Apps Server Preview in a virtual machine instance on one of these servers.

Do not install any services or roles that depend on the Web Server (IIS) role on port 80, 443, or 809 because Office Web Apps Server Preview periodically removes web applications on these ports.

Do not install any version of Office. You must uninstall Office before you install Office Web Apps Server Preview.

The Office Web Application Server really doesn’t play well with others. It pretty well demands that it is installed in isolation from other servers, which in reality means that a small SharePoint farm will consist of 3 servers – one SharePoint front end server, one SQL server, and one Office Web Applications server, and while virtualization makes this much more palatable, it may be a bit much for some smaller organizations to swallow.

Setting It Up

The official (pre-release) document on planning and deploying the Office Web Application server can be found here and here respectively. Originally, I had planned on putting together a step by step walkthrough, but Steve Peschka from Microsoft published this article today that does precisely that.

Steve’s article is great because it describes the process of setting up the server with both http and https. Http is fine if all traffic is internal, but if you will have any external traffic, you must set it up with SSL (if security matters at all to you..), and the server will support only one zone, you cannot use both http and https. As you would expect, setting it up for SSL is more complex than for http.

All of the setup is done with Powershell. Powershell is fantastic, and highly useful, but I don’t think that anyone would claim that it’s easy to get started with, especially for small farm administrators,

I think that it can safely be concluded that it’s significantly harder to get the Office Web Applications installed with 2013 than it was with 2010.

Takeaways

Anyone running a two server SharePoint farm with the Office Web Applications on 2010 will wind up with a three server farm after upgrading to SharePoint 2013. This can be done via virtualization, or by standing up another physical box. Depending on the workload, the Office Web Application server doesn’t need to be particularly powerful, but no matter what, it introduces an added level of complexity. For those that heavily leverage the server, that’s a good trade-off, but for others, perhaps not.

The Office Web Applications are a fantastic set of tools, and they have been significantly improved in 2013. I am however concerned that the lack of a smooth architectural transition path from 2010 combined with the lack of a simple setup process may keep some (smaller) organizations away from it. Of course, those organizations will also have the option of moving to Office 365 where these services will already be set up and running.

Something tells me that this may just be the point.

Why I Love Office 365

Published October 21, 2011

OK, so my company is a Microsoft partner, and we’re supposed to like everything that they throw our way right? That’s actually not true. I’ll certainly give most things that they do a fair shot. It’s also true that I’m willing to sacrifice a certain amount of capability for either ease of use, or for the way that Microsoft products work well together, but as I noted in a previous post, I only gave up my BlackBerry when Microsoft came out with a product that was worth using.

My company is small (currently 6 people) and widely distributed. Cloud solutions make perfect sense to us,and we have been using Exchange Online for over 2 years now. Our requirements for SharePoint went beyond what was possible in BPOS’ offering, but since migrating to Office 365 6 months ago, the new SharePoint online fits the bill, and more and more of our corporate assets live there now.

UnlimitedViz is currently primarily a SharePoint services company focused on Business Intelligence, and a significant portion of those services involve architecting SharePoint environments at a lower level, which involves sizing servers, making resource decisions, etc. I personally love designing solutions and watching them come to life. We are certainly more than capable to maintain our own SharePoint infrastructure, so why would we want to use an admittedly more limited version of the product that is maintained by someone else?

Pretty much because it’s maintained by someone else.

As mentioned above we’re small, and we need to be focused on what we do best, which is providing services to our customers, and building product. Maintaining internal systems, no matter how good we are at it, is a distraction, and a significant cost, both capital and operational. The per user cost of Office 365 is pretty simple to justify from just a cost standpoint, but there are many more benefits that are brought to the table.

No matter what the location of a team member, they can easily access what they need to. Lync brings that down to the voice and IM communication level. No need to mess around with access methods, VPNs, Firewalls, Reverse Proxy servers and the like. We can get to our content easily on site, at home via whatever device we happen to need. Granted, I could set that stuff up on-premise, but now I don’t have to! I also know that my data is safe, and the performance is going to be good. Two months ago, Exchange online suffered an outage for about two hours (the only hiccup I’ve experienced so far). My initial reaction was “what can I do to fix this”, but that was quickly superseded by “It’s not my problem to fix”, so I just sat back and got other work done.

As we bring more customers onto Office 365, supporting them just gets simpler. A simple client request can be acted upon immediately by launching a browser window, and connecting to their site, seamlessly. With most onsite installations, I need to start a virtual machine, connect through a VPN client, and then hope that the correct tools are installed on the VM, or the client site, depending on the access mechanism. I try to keep a VM image available for every type of VPN client used, which is a hopeless and necessary task due to the incompatibilities between clients. In my opinion, the world will be a better place when VPN clients are eliminated (or at least consolidated”).

Customers using Office 365 don’t need VPN clients, and it makes it that much easier (and cheaper for them) for us to support them.

There a a whole bunch of great features about Office 365 (Shared OneNote files accessed via Windows Phone, browser and client is a good one, not to mention Lync), but the reason that I really like it is that it’s solid, it works, and it lets my business focus on using its tools, not maintaining them.

Upgrading From WSS 3.0 to Search Server Express

Published September 21, 2011

About a year ago, I wrote a couple of articles (here and here) that discuss the merits of using Search Server Express 2010 instead of SharePoint Foundation. It really boils down to the fact that you get more stuff, and it’s still free. As opportunities for Foundation arise, we have been installing SSE and our customers are quite pleased with the result.

I recently had the opportunity to perform an in place upgrade of a WSS 3.0 site that we had built a few years ago to Foundation, and I of course decided to use SSE instead. As it turns out, the upgrade wasn’t quite as straightforward as I had hoped.

Normally, when you perform an in place upgrade from WSS to Foundation, you first install the bits, and then run the Products and Technologies Configuration Wizard, which in turn detects the pre-existing WSS installation and offers to upgrade it. Unfortunately, this doesn’t happen with SSE. The Wizard only prompted for a new or existing Farm.

The next step was to uninstall SSE, and to Install Foundation, once this was done, the Wizard did detect the existing installation, and properly upgraded the entire farm. Once this was done, I thought “why wait?” and I went ahead and laid down the bits for Search Server Express and then for Office Web Applications.

Everything seemed alright, but when I tried to start the services on the server, they simply weren’t there. It also wasn’t possible to create the corresponding Service Applications for either SSE or for the Office Web Applications. After much head pounding, I decided to uninstall everything, OWA, SSE, and Foundation (CAREFULLY as outlined here..), and then Install SSE alone, joining it to the Pre-existing farm.

Once that was done, everything showed up properly, and I was able to properly start the appropriate search services, and OWA services, and to create the appropriate service applications.

So as it turns out, order of operations is pretty important in this scenario. If you want to upgrade from WSS 3.0 to Search Server Express 2010 (using the in place upgrade approach), you’ll want to follow these steps:

Install SharePoint Foundation 2010 on your server
Run the Products Configuration Wizard, and perform the upgrade
Uninstall SharePoint Foundation from the server, removing it from the farm
Install Search Server Express 2010 on the Server
Run the Products Configuration Wizard, and re-join the existing farm
Test the site to ensure that it’s functional
(optional) Install any appropriate Service Packs and/or hot fixes for SSE
(optional) Run the Products Configuration Wizard to update the databases (if step 7 was performed)
(optional) If desired, Install Office Web Applications, and any appropriate Service Packs for OWA
Run the Products Configuration Wizard to complete the OWA installation
Start all necessary services, create the necessary service applications (search is a big one….)
Create a basic Search Center and configure your site collection to use it.

Hopefully this helps any other folks in the same situation.

Bye Bye Blackberry

Published November 30, 2010

It’s old news by now, but I didn’t want to write about this until I had a little usage under my belt. I’ve also been too busy to write, I have about 5 other posts queued up that I just need to get to, but I wanted to document my experience with my new Windows Phone 7.

In a nutshell, I absolutely love it. I couldn’t imagine going back.

I’ve been a Blackberry user since around 1996 with the original RIM 950. For years Blackberry was not only an innovator in mobile messaging, but their devices were rock solid. I don’t know how much abuse my Blackberries took over the years, including being dropped in water (yes that kind of water), dropped kicked, whatever. After a fall that cracked its window, my 8800 kept on ticking. The Blackberry was also top notch for message delivery through it’s BES for years. Other contenders came on the scene, but I always felt that all I wanted in a mobile device was email.

If you’re reading this, you know that I live in a Microsoft centric world,and although it would have been politically expedient of me to use a Windows Mobile device,I was never impressed with them. I was never tempted by the iPhone, which I regard as more of a toy than anything else. I was beginning to become interested in the Android, but remained leery from a reliability standpoint.

I was however becoming increasingly frustrated with the performance of the BlackBerry, particularly when it came to consuming web content, which was increasingly becoming a requirement. Web content was also very hard on the battery, and when travelling, I was lucky to get 8 hours without a charge. Another big cloud of doubt to me was the relevance of BES (Blackberry Enterprise Server) in a world of Exchange ActiveSync. It just seemed like way too much overhead and licensing to support mail/contact/calendar sync.

Everything changed when I heard about the Windows Phone 7 this past spring. Finally, Microsoft would have a product that not only competed, but in my opinion leapfrogged the competition. In my opinion, RIM wasn’t doing anything particularly innovative, so I resolved to try it out when it became available.

My biggest concern is that the vision that was spelled out in the original announcements wouldn’t be realized, or would be in some way compromised (we’ve seen this before from our friends in Redmond). I was thrilled to find that this wasn’t the case.

I received my Samsung Focus 2 1/2 weeks ago. I removed the SIM card from my Blackberry, put it in my Focus, and the Blackberry (a curve) hasn’t been turned on since. The first thing that I was asked was my Windows Live ID, and it immediately started to fill up with contacts and pictures from Facebook and Windows Live. A quick configure of 2 Exchange accounts (one on BPOS and one on premise) and everything was centralized nicely.

I have had precisely no problems with it in the past 2 weeks. Most interestingly to me, is that I’ve experienced no dropped calls in that period. My running joke was always that it wasn’t a mobile call unless it got dropped at least one. I always blamed the carrier, but I’m using the same SIM! It’s anecdotal, but the phone itself is at least good.

Working with office apps is very very slick. I particularly like the way that it works with OneNote content in the cloud (on Windows SkyDrive). In fact, the phone itself is a really nice demonstration of the overall benefits of cloud computing, in particular device independence. Combining the phone, the PC, and the new EXOPC slate that I recently acquired, makes for a pretty slick demonstration.

It’s not perfect – I have yet to be able to get the Office hub to talk to SharePoint, something pretty important to me…. but it does render nicely in the browser.

Reliability is of course something of a question mark yet. I have managed to drop it twice with no ill effects, and I’m not really anxious to put it to the test. I am however pretty hard on stuff, and if it’s fragile, you’ll likely hear it here first.

I just find myself pleasantly surprised by the way it works as I discover them, and that’s nice. It’s also pretty nice having something from Microsoft that’s pretty much the coolest thing in its space. At least for now. A big tip of the hat to the designers from here.

I don’t leave the Blackberry angry… it’s served me very very well over the years, but we appear to have gone our separate ways, and I wish it well. Given that I live in RIM’s back yard, it really is too bad, but I have made my choice, and I’m very, very happy with it.

3 Comments