Deploy Office Web Apps Server

Deploy Office Web Apps Server

Deploying Office Web Apps Server involves installing some prerequisite software and running a few Windows PowerShell commands, but overall the process is designed to be pretty straightforward. This article walks you through the procedures to get your servers ready, then gives you the Windows PowerShell commands to configure the Office Web Apps Server farm.

Prepare servers to run Office Web Apps Server

---

Perform these procedures on all servers that will run Office Web Apps Server.

Figure: The steps to prepare servers for Office Web Apps Server

Step 1: Install prerequisite software for Office Web Apps Server

---

Windows Server 2008 R2 and Windows Server 2012 have slightly different prerequisites, so select the appropriate procedure below to install the correct ones for your operating system.

On Windows Server 2008 R2

---

1. Install the following software:
• Windows Server 2008 R2 Service Pack 1
• .NET Framework 4.5
• Windows PowerShell 3.0
• Platform update for Windows 7 SP1 and Windows Server 2008 R2 SP1 (KB2670838)

1.     Open the Windows PowerShell prompt as an administrator and run these commands to install the required roles and services.

Import-Module ServerManager

Then, run these commands:

Add-WindowsFeature Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,Web-Security,Web-Windows-Auth,Web-Filtering,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Console,Ink-Handwriting,IH-Ink-Support

If prompted, restart the server.

Step 2: Install Office Web Apps Server

---

Complete these steps on any servers that will run Office Web Apps Server.

---

1. Download Office Web Apps Server from the Microsoft Download Center.
2. Do one of the following:
• For Windows Server 2012, open the .img file directly and run Setup.exe.
• For Windows Server 2008 R2 SP1, use a program that can mount or extract .img files, then run Setup.exe.
3. On the Read the Microsoft Software License Terms page, select I accept the terms of this agreement and click Continue.
4. On the Choose a file location page, select the folder where you want the Office Web Apps Server files to be installed (for example, C:\Program Files\Microsoft Office Web Apps) and select Install Now. If the folder you specified doesn’t exist, Setup creates it for you.
5. When Setup finishes installing Office Web Apps Server, choose Close.
6. Download and install the Office Web Apps Server update KB2810007.
   Check for the most current Office Web Apps Server updates by reviewing the 2013 list on the TechNet Update center for Office, Office servers, and related products.

Step 3: Install language packs for Office Web Apps Server

---

Office Web Apps Server 2013 Language Packs let users view web-based Office files in multiple languages, whether they’re opened from SharePoint 2013 document libraries, Outlook Web Access (as attachment previews), and Lync 2013 (as PowerPoint broadcasts). Learn more about how the language packs work in Planning language packs for Office Web Apps Server.

To install the language packs, follow these steps.

---

1. Download the Office Web Apps Server Language Packs from the Microsoft Download Center.
2. Run WebAppsServerLP_en-us_x64.exe.
3. In the Office Web Apps Server Language Pack 2013 Wizard, on the Read the Microsoft Software License Terms page, select I accept the terms of this agreement and select Continue.
4. When Setup finishes installing Office Web Apps Server, choose Close.

Deploy a single-server Office Web Apps Server farm that uses HTTP

---

If you’re only deploying Office Web Apps Server for testing or internal use, and you don’t need to provide Office Web Apps Server functionality to Lync Server 2013, this procedure is for you. Here, you’ll install a single-server Office Web Apps Server farm that uses HTTP. You won’t need a certificate or load balancer, but you will need a dedicated physical server or virtual machine instance that isn’t running any other server application.

You can use this Office Web Apps Server farm to provide Office Web Apps functionality to SharePoint 2013 and Exchange Server 2013.

Figure: The steps to deploy Office Web Apps Server

Step 1: Create the Office Web Apps Server farm

---

Use the New-OfficeWebAppsFarm command to create a new Office Web Apps Server farm that consists of a single server, as shown in the following example.

New-OfficeWebAppsFarm –InternalURL "http://servername" -AllowHttp –EditingEnabled

For HTTP and HTTPS

New-OfficeWebAppsFarm -InternalUrl "https://server.contoso.com" -ExternalUrl "https://wacweb01.contoso.com" -CertificateName "OfficeWebApps Certificate" -EditingEnabled

Parameters

• –InternalURL is the name of the server that runs Office Web Apps Server, such as http://servername.
• –AllowHttp configures the farm to use HTTP.
• –EditingEnabled enables editing in Office Web Apps when used with SharePoint 2013. This parameter isn't used by Lync Server 2013 or Exchange Server 2013 because those hosts don't support editing.

Additional parameters that configure translation services, proxy servers, ClipArt support, and Online Viewers are described in New-OfficeWebAppsFarm.

Step 2: Verify that the Office Web Apps Server farm was created successfully

---

After the farm is created, details about the farm are displayed in the Windows PowerShell prompt. To verify that Office Web Apps Server is installed and configured correctly, use a web browser to access the Office Web Apps Server discovery URL, as shown in the following example. The discovery URL is the InternalUrl parameter you specified when you configured your Office Web Apps Server farm, followed by /hosting/discovery, for example:

http://servername/hosting/discovery

If Office Web Apps Server is working as expected, you should see a Web Application Open Platform Interface Protocol (WOPI)-discovery XML file in your web browser. The first few lines of that file should resemble the following example.

Step 3: Configure the host

---

The farm is now ready to provide Office Web Apps functionality to hosts over HTTP. Visit the following articles for more information about how to configure hosts.

• Configure Office Web Apps for SharePoint 2013
• Office Web Apps Server Integration (Exchange Server 2013)

If you see “500 Web Service Exceptions” or “500.21 – Internal Server Error” messages

---

If features of the .NET Framework 3.5 were installed and then removed, you might see “500 Web Service Exceptions” or “500.21 – Internal Server Error” messages when you run OfficeWebApps cmdlets. To fix this, run the following sample commands from an elevated command prompt to clean up settings that could prevent Office Web Apps Server from functioning correctly:

For Windows Server 2008 R2

%systemroot%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -iru

iisreset /restart /noforce

For Windows Server 2012

dism /online /enable-feature /featurename:IIS-ASPNET45

Configure SharePoint 2013 to use Office Web Apps Server

---

Choose one of the following sections depending on whether you want to use HTTP or HTTPS. HTTP is generally recommended only for test environments. In production environments, the more secure HTTPS protocol is the better choice.

Step 2: Create the binding between SharePoint 2013 and Office Web Apps Server

---

Run the following command, where <WacServerName> is the fully qualified domain name (FQDN) of the URL that you set for the internal URL. This is the point of entry for Office Web Apps Server traffic. For this test environment, you need to specify the –AllowHTTP parameter to allow SharePoint 2013 to receive discovery information from the Office Web Apps Server farm by using HTTP. If you don’t specify –AllowHTTP, SharePoint 2013 will try to use HTTPS to communicate with the Office Web Apps Server farm, and this command won’t work.

New-SPWOPIBinding -ServerName <WacServerName> -AllowHTTP

After running this command, you should see a list of bindings displayed at the Windows PowerShell command prompt.

Need help? See New-SPWOPIBinding.

Step 3: View the WOPI zones for the SharePoint bindings

---

Office Web Apps Server uses zones to determine which URL (internal or external) and which protocol (HTTP or HTTPS) to use when it communicates with the host, in this case, SharePoint 2013. By default, SharePoint Server 2013 uses the internal-https zone. Run the following command to see what your current zone is.

Get-SPWOPIZone

The WOPI zone displayed by this command should be internal-http. If it’s displayed correctly, skip to step 5. If it isn’t, see the next step.

Need help? See Get-SPWOPIZone.

Step 4: Change the WOPI zone to internal-http

---

If the result from Step 3 was internal-https, run the following command to change the zone to internal-http. You need to make this change because the zone of SharePoint 2013 must match the zone of the Office Web Apps Server farm.

Set-SPWOPIZone –zone “internal-http”

 If you have a SharePoint farm that’s internal and external, you need to run the following command to change the zone to external-https.

Set-SPWOPIZone –zone “external-https”

Verify that the new zone is internal-http by running Get-SPWOPIZone again.

Need help? See Set-SPWOPIZone and Get-SPWOPIZone.

Step 5: Change the AllowOAuthOverHttp setting in SharePoint 2013 to True

---

To use Office Web Apps with SharePoint 2013 over HTTP in a test environment, you need to set AllowOAuthOverHttp to True. Otherwise Office Web Apps won’t work. You can check the current status by running the following example.

(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp

If this command returns False, run the following commands to set this to True.

$config = (Get-SPSecurityTokenServiceConfig)

$config.AllowOAuthOverHttp = $true

$config.Update()

Run the following command again to verify that the AllowOAuthOverHttp setting is now set to True.

(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp

Verify the documents with office web app features

Exchange 2010 Stet By Step Installation

System Requirements

First, you need to make sure that your Active Directory (AD) environment and your Exchange server meet the minimum requirements:

·         AD forest functional level is Windows Server 2003 (or higher)

·         AD Schema Master is running Windows Server 2003 w/SP1 or later

·         Full installation of Windows Server 2008 w/SP2 or later OR Windows Server 2008 R2 for the Exchange server itself

·         Exchange server is joined to the domain (except for the Edge Transport server role)

Prerequisites

In this example we are going to install Exchange 2010 on a Windows Server 2008 R2 operating system. Before installing Exchange we need to install some Windows components. It's important that you don't miss anything here because the Exchange 2010 installer does not provide very good feedback if Server 2008 R2 is missing required components.

1.     Install the 2007 Office System Converter: Microsoft Filter Pack

2.    Add the appropriate Windows components/features

3.    Open PowerShell via the icon on the task bar or Start >> All Programs >> Accessories >> Windows PowerShell >> Windows PowerShell. Be sure that PowerShell opened with an account that has rights to install Windows components/features.

4.    Run the following command: Import-Module ServerManager

5.    For a typical install with the Client Access, Hub Transport, and Mailbox roles run the following command: Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart. For a full matrix of the required Windows components with regards to the Exchange server roles see: http://technet.microsoft.com/en-us/library/bb691354.aspx#WS08R2

6.    If your Exchange server will have the Client Access Server role set the Net.Tcp Port Sharing Service to start automatically

·         Open PowerShell via the icon on the task bar or Start >> All Programs >> Accessories >> Windows PowerShell >> Windows PowerShell. Be sure that PowerShell opened with an account that has rights to modify service startup settings.

·         Run the following command: Set-Service NetTcpPortSharing -StartupType Automatic

Exchange 2010 Installation

Now we're ready to run the Exchange 2010 installer. We'll go through a typical installation that includes the Client Access, Hub Transport, and Mailbox roles. This is what you will want to install if you are only going to be running one Exchange server. If you scale out your Exchange architecture with multiple servers then you will want to familiarize yourself with the Exchange server roles for a proper deployment.

1.     Logon to the desktop of your soon to be Exchange server with a Domain Admin account.

2.    Run setup from the Exchange 2010 media.

3.    Click on "Step 3: Choose Exchange language option" and choose one of the options (Install only languages from the DVD will be fine in most cases).

4.    Click on "Step 4: Install Microsoft Exchange."

5.    Click Next at the Introduction page.

6.    Accept the license terms and click Next.

7.    Make a selection on the Error Reporting page and click Next.

8.    Stick with the default "Typical Exchange Server Installation" and click Next.

9.    Choose a name for your Exchange Organization and click Next.

10.  Make a selection on the Client Settings page and click Next.

11.   If you want your Exchange server to be available externally then choose a domain name such as mail.myorganization.com, click Next.

12.  Make a selection on the Customer Experience Improvement Program page and click Next.

13.  If all the prerequisites are there then you can click Install.

14.  Grab a cup of coffee or take a walk while the installation process does its thing.

15.  When the installation has finished go back to the Exchange installation page click on "Step 5: Get critical updates for Microsoft Exchange."

16.  Install Microsoft Update (if necessary) so that Windows update will check for non-OS updates, and verify that there are no Exchange updates.

Configuring incoming email in SharePoint 2010 with Exchange – Step by Step Guide

Reference Article : http://sharepointgeorge.com/2010/configuring-outgoing-email-sharepoint-2010/
Today we continue down our journey in setting up our SharePoint 2010 farm, with the focus on configuring incoming email for SharePoint 2010.  When SharePoint 2007 was released, there was a lot of discussion and rumors around Exchange 2007 being the last version of Exchange to provide Public Folder support, and that SharePoint 2007 was going to be it’s alternative. Microsoft quickly changed its stance and continues to support Public folders in Exchange 2010.  However, there still might be a number of compelling reasons why you would want to consider storing incoming email messages in SharePoint 2010 document libraries, instead of public folders.  You can read more about the benefits of using email-enabled SharePoint libraries in one of my article’s here.
In today’s post, I will provide you with a comprehensive step by step guide in configuring your SharePoint 2010 server in conjunction with Exchange 2010, to provide successful delivery of incoming email directly to your SharePoint Web Applications.

The environment

This article builds on the SharePoint Farm setup that I have documented here. It consists of the following servers which would form a common basis in most large organizations.

• Windows 2008 R2 server running Active Directory Domain Services
• Windows 2008 R2 server running SQL 2008 R2
• Windows 2008 R2 server running SharePoint 2010 RTM
• Windows 2008 R2 server running Exchange 2010 RTM
• Windows 7 client running Office 2010 RTM

The SMTP service

SharePoint 2010 is reliant on the SMTP service which is a Windows 2008 feature and we must install this on our SharePoint 2010 front-end web server.
Navigate to your Start Menu / Administrative Tools / Server Manager.  Click on the Features node and select Add Feature.  Scroll down and select SMTP Server and click on Add Required Role Services.

Click Next, Next and Install.

Click Close
We now need to install the II 6.0 Management Tools on our Windows 2008 R2 server in order to configure our SMTP service.  If IIS 6.0 Manager is not already installed you must do so via, Start / Administrative Tools / Server Manager.  Click on the Roles node and select Role / Add Role Services.  Then select Management Tools and IIS 6 Management compatibility.  Click Install.
We can now launch the IIS 6 Manager via Start / Administrative Tools.

Right click on SMTP Virtual Server #1 and select properties.
Under the General tab, I have enabled logging and encourage doing so at the start in the event we need to do some troubleshooting.  You can turn logging off after successful testing.

Click on the next tab, “Access”.
Click on “Authentication” and ensure that Anonymous access is selected.

Next, click on “Connection” and ensure “All except the list below” is selected.

Finally, click on “Relay”, and ensure that “Only the list below” is selected and that “Allow all computers which successfully authenticate to relay, regardless of the list above” is also checked.

Now click on the Messages Tab and make any necessary adjustments that you see fit, such as potentially increasing the message size to allow for the delivery of larger emails with attachments into your SharePoint Libraries and Lists.

Next click on the Delivery Tab in which I normally leave all the defaults in place.

We can skip the LDAP routing tab as there are no settings required to be configured in this area.
Lastly, the Security tab should list the default permissions as per the below.  No changes are necessary in this area.

We next journey into the “Domains” are within IIS 6 Manager and a domain name should be listed, which by default is the fully qualified domain name of the machine.
Right click on the Domain Name and select properties and take note of the Drop directory.

Finally, we now just need to confirm that our SMTP service is set to start automatically in the event the server is restarted.  I can tell you now that the service is by default set to Manual.
Venture into Start / Administrative Tools / Services.
Scroll down your list of services and ensure that the Simple Mail Transfer Protocol (SMTP) is set to Start-up type, Automatic.

We have now completed the configuration of our SMTP service on our SharePoint Server.

Exchange 2007/2010 Connectors

Part two of the implementation of configuring incoming email in SharePoint is to configure our connectors in Microsoft Exchange.  Now even though this is not a requirement, most organisations running SharePoint 2010 or 2007 will also be running a recent version of Microsoft Exchange, hopefully either 2007 or 2010.  Exchange 2010 or 2007 will provide you with that extra layer of protection ensuring that all the necessary message hygiene has been performed via its inbuilt Anti Spam Agents on the Edge or Hub Transport Server in conjunction with some form of email antivirus such as Microsoft’s Forefront for Exchange, before the message is delivered to the SharePoint 2010 List or Library.
My instructions and screen captures below are from an Exchange 2010 server which are pretty much identical and applicable to Exchange 2007.
Let’s begin by launching the Exchange Management Console / Organization Configuration / Hub Transport.
Click on Send Connectors / Actions / New Send Connector.
Type in a descriptive name for your Send Connector and then select Internal as the type.

Click Add and enter the Address space as the fully qualified domain name of the server where the SMTP service is installed (i.e. your SharePoint Server)

Click Next
Enter the IP address of the server which also hosts the SMTP service.

Click Next
Select “None” as your smart host authentication settings

Click Next
Ensure your Hub Transport Server has been added.

Click Next

Click New and then click Finish
The end result will be that the Send connector will route email to the SMTP service sitting on our SharePoint Server.

The Directory Management Service

SharePoint 2010 allows you to leverage Active Directory Domain Services (AD DS) so that contacts that are created when you email enable document libraries or lists are stored in a designated Organizational Unit within your AD DS infrastructure.  So why would you want to enable Directory Management Service?  Purely for the fact that by storing these contacts in AD, you are allowing your users to locate email enabled libraries and lists easily from within their Outlook Address book.
Let’s begin by creating an Organizational Unit in Active Directory.
From your Active Directory server, click Start / Administrative Tools / Active Directory Users and Computers.
Right click on your domain object and select New / Organizational Unit
Type in a descriptive name

Click Ok.
The next step is imperative and very important that we get this right.  I have seen on many occasions where incorrect permissions were applied and all sorts of problems were encountered when libraries or list were email enabled.
In summary, we need to provide our Central Administration Application pool identity account specific permissions to our recently created Organizational Unit to be used for creating and deleting contacts for our SharePoint 2010 libraries and lists when they are either email enabled or email disabled.
Right click on the recently created Organizational Unit and click on Delegate Control.  This will invoke the Delegation of Control Wizard.

Click Next.
We will now add the Central Administration application pool account which you can confirm from IIS Manager as per the below screen capture.

Add the necessary Account.

Click Next.
Click Create a custom task to delegate.

Click Next
Click “This folder, existing objects in this folder, and creation of new objects in this folder’.

Click Next
Click on Create All Child Objects and Delete All Child Objects.

Click Finish.
Before we finish off our configuration of AD DS and the Directory Management Service we need to provide our Central Administration application pool account with Delete Subtree permissions.
We need to ensure that “Advanced Features” from within Active Directory Users and Computers (ADUC) is active before we venture into the security tab of our SharePoint organizational unit.  If you do not enable Advanced Features, the security tab will not be visible.
From within ADUC, click on View and select Advanced Features.
Right click on our SharePoint 2010 Organizational Unit and select Properties.
Click on the Security Tab / Advanced /and Edit the CA Application Pool Identity Account.

Select Allow for “Delete Subtree”

Click on OK and Apply.
After assigning these permissions, you must run IISRESET on your SharePoint server.

Configuring Incoming e-mail settings in Central Administration

Navigate to Central Administration / System Settings / Configure incoming e-mail settings.

Select Yes to “Enable site on this server to receive e-mail”
Select “Automatic” for Setting mode.
Select “Yes” to use the SharePoint Directory Management Service to create distributions groups and contacts.
Enter your Active Directory container details, i.e. the Organizational Unit container that we created specifically for our SharePoint 2010 contacts.
Ensure that your SMTP server details are correct, this should be the fully qualified domain name of your SMTP service that was installed on your SharePoint Server.

Finally, ensure “Accept mail from all e-mail servers” is selected.

Click OK.
Please note that this process will configure the necessary permissions on the email drop folder listed in IIS 6 Manager.  In summary, the following permissions are added;
WSS_Admin_WPG – Full Control and
WSS_WPG – Read & Execute / List folder Contents / Read

Ensure that these accounts are added successfully and on the rare occasion in which it isn’t, you will need to add them manually.

Testing the configuration

From within any document library or list, click on Library / Library Settings.

Click on Incoming e-mail settings.
Select “Yes” to allow this document library to receive e-mail.
Select your email attachment options and ensure that Save original e-mail is set to Yes.
Lastly, ensure that you Accept e-mail messages from any sender is selected.

Click OK.
This is your first step to ensure that all of the above configuration is in place.  If you do receive an error, it’s most likely going to be permissions related against your Organizational Unit, i.e. SharePoint may not have the privilege to add the contact in Active Directory.
Let’s navigate back to ADUC and confirm that our “testing” contact is created under the SharePoint 2010 Contacts Organizational Unit.

Let’s next navigate to our Exchange 2010 server and ensure it is also listed there with an SMTP address against it.
Launch your Microsoft Exchange Management console and navigate to Recipient Configuration / Mail contact.

Right click on the Contact and select Properties / E-Mail Addresses.
Ensure that both an internal and external routable email address is listed.

From your favorite email client, send a test email to the document libraries’ external SMTP address.
Navigate to your recently email enabled document library and hopefully after a couple of minutes (SharePoint Job timer service delay) you should have received your test email.

Well! That’s all that is to it, from start to finish.  Apart from sending a test email, there are a couple of other scenarios that you should test to ensure complete seamless integration with the SharePoint 2010 Directory Management Service.  Within the same document library, modify the email address to something different and ensure that this change also flows through to Active Directory. You should also try disabling incoming email from that same library and ensure that the contact is completely removed from Active Directory.  If you pass all of these tests scenarios, then we are comfortable in knowing that the correct delegation was provided to our Central Administration Pool Account against our SharePoint Contacts Organizational Unit.

Creating a New Receive Connector for SharePoint outgoing email

Note that the Send Connector was created under the Hub Transport settings of the Organization Configuration. Receive Connectors, on the other hand, fall under the Hub Transport settings of the Server Configuration. Go there now and, in the right-hand panel, click New Receive Connector

·         Give it a name and choose the intended use for that connector (e.g. Custom). Click Next.

·         Leave the Local Network settings as is. Click Next.

·         When you’re already in the Remote Network Settings window, select a range of IP addresses in the list box to change it. Basically, a single item is a range of IP addresses of servers from which mail will be received.

·         You’ll need to enter the IP address of the SMTP server (the SharePoint Server in this case) for the Start Address, as well as an End Address in case you have additional servers in play.

·         Click OK. Then click Next.

·         In the next window, click New to commence creation of the new connector.

·         When the process completes, click Finish.

·         Once inside the SharePoint Outgoing Properties window, navigate to the Permission Groups tab and check Anonymous users. Click OK.

·         With that, your Receive Connector will now be ready to go.

·         Next, we’ll show you how to configure your outgoing email settings from Central Administration.

·