Office web apps server 2020

Lync Server 2013: введение в Office Web Apps Server

Стоило мне только подумать, что команда Microsoft Lync Server не будет добавлять новую роль для Lync Server, так сразу появилась информация о Office Web Apps Server, который необходим для презентаций PowerPoint в Lync Server 2013. Да, именно так: для того чтобы пользователи Lync 2013 могли задействовать PowerPoint в конференциях Lync, необходим сервер с новой ролью. Однако эта роль, которую требуется развернуть, не входит в состав Lync Server 2013; она является одной из ролей SharePoint 2010, который может быть уже развернут у вас. Давайте рассмотрим особенности этой роли и разберем, как она работает совместно с Lync 2013

Что такое Office Web Apps Server?

Office Web Apps Server — это следующее поколение Microsoft Web Access Companion Server; он дает возможность таким приложениям как Lync и SharePoint эффективно транслировать презентации PowerPoint в высоком разрешении на различные клиентские системы. Lync Server 2013 использует Office Web App Server для передачи презентаций клиентам Lync 2013 – в том числе и Lync Web App — в любом собрании по сети (Lync Online Meeting), например конференции. Этот новый подход делает возможным следующее:

• использование экранов с высоким разрешением;
• поддержку возможностей PowerPoint, таких как анимация, смена слайдов и встроенное видео.

Поскольку Office Web Apps Server не является одной из ролей Lync 2013, он не устанавливается на каком-либо сервере Lync, а требует наличия выделенного сервера (или серверов). Также возможна виртуализация этого сервера, необходимости разворачивать его на физическом оборудовании нет.

В Lync 2010 появились досадные нюансы при совместном удаленном использовании презентаций в Lync Web App. С течением времени удаленные или анонимные пользователи, присоединяющиеся к конференциям подобным способом, начинали испытывать затруднения, которые приводили к ограниченному использованию некоторых функций. Вот несколько наиболее известных ограничений метода, используемого в Lync 2010 для форматирования и отображения документов.

• Встроенное средство для просмотра PowerPoint доступно только для платформы Windows, что создает проблемы для пользователей Linux или Mac.
• Среда Silverlight 4 или более новая необходима для подключения к собранию с помощью Lync Web App; Silverlight — это компонент Microsoft, который позволяет пользовательскому устройству подключаться к собранию с помощью Lync Web App, когда пользовать нажимает «Подключиться к собранию по сети» (Join Online Meeting) в приглашении на собрание, отправленном организатором. Однако лишь немногие мобильные устройства поддерживают Silverlight.

Каким образом эти трудности устранены в Lync 2013? Lync Server 2013 использует компонент SharePoint Office Web Apps Server, чтобы решить проблемы, существовавшие в Lync 2010. Office Web Apps Server и его возможность обрабатывать презентации PowerPoint помогают в ситуациях, упомянутых выше, которые подчас доставляли множество неудобств пользователям, подключенным к собранию удаленно.

При использовании Lync 2013 совместно с Office Web App Server доступны следующие возможности.

• Усовершенствование PowerPoint: вы получаете экран с большим разрешением для анимации, переключения слайдов и просмотра встроенного видео.
• Поддержка дополнительных мобильных устройств: поскольку Lync 2013 использует стандартные Dynamic HTML (DHTML) и JavaScript для передачи презентаций PowerPoint, а не измененные DHTML и JavaScript, которые использовались в Lync 2010, теперь большее количество устройств может подключаться к собраниям.
• Прокручивание презентаций PowerPoint: пользователи, имеющие соответствующие права, могут пролистывать презентацию, независимо от того, что показывает ведущий.

Для того чтобы воспользоваться этими функциями, вам необходимо ассоциировать Lync 2013 с Office Web Apps Server, указав URL, содержащий полное доменное имя FQDN сервера или фермы серверов, на которых установлена эта роль, в программе построения топологии Lync topology builder.

Office Web Apps Server работает независимо от того, используете ли вы SharePoint 2013 или SharePoint 2010. Преимущество применения SharePoint 2013 заключается в возможности развертывания и управления Office Web Apps Server как более независимым продуктом, в SharePoint 2010 они (Office Web Apps Server и SharePoint) более тесно связаны, что затрудняет применение обновлений к ферме серверов Office Web Apps Server.

Устранение основных недостатков

Появление Office Web Apps Server на первый взгляд может выглядеть как недобросовестная реклама: сначала вы слышите, что в Lync 2013 роли были объединены, а затем узнаете, что вам требуется установить дополнительную роль. Но на самом деле вы разворачиваете не роль Lync Server 2013, а дополнение к серверу SharePoint. То, как специалисты Microsoft устранили основные трудности в области презентаций, которые отмечались в Lync 2010, не может не радовать.

Поделитесь материалом с коллегами и друзьями

Exchange 2013 with Office Web Apps Server Integration

Introduction

With Exchange 2007 and 2010, Outlook Web Access/App [OWA] users can preview documents attached to e-mails directly from their browser. This feature, known as WebReady Document Viewing, converts supported documents (Word, Excel, PowerPoint or PDF) to HTML and displays them in the web browser, allowing users to read Word documents, for example, without the need to have Word installed or first downloading the file.

Whenever a user receives an e-mail with a supported attachment, an “Open as Web Page” link appears next to the attachment:

Figure 1: WebReady Document Viewing Link in Exchange 2010

All the user needs to do to preview the attachment is click on the link and the WebReady Viewing version of the document will open:

Figure 2: WebReady Document Viewing in Exchange 2010

With Exchange 2013 there is another method to preview these types of documents. To provide an even better experience to users, we can integrate Exchange 2013 with Microsoft Office Web Apps Server [OWAS].

Up until now, to provide the WebReady Document Viewing functionality, Microsoft relied partially on 3rd-party components. With all the security concerns that there has been around this functionality, replacing it with OWAS might not be such a bad idea. This also means that Microsoft has full control over all the components used by this feature.

By default, the following file types are displayed using OWAS:

• Word documents (doc, docx, dotx, dot and dotm extensions);
• Excel documents (xls, xlsx, xlsm, xlm and xlsb extensions);
• PowerPoint documents (ppt, pptx, pps, ppsx, potx, pot, pptm, potm and ppsm extensions).

With previous editions of Exchange, WebReady Document Viewing is built in to Exchange. With OWAS integration in Exchange 2013, SharePoint 2013 and Lync Server 2013, when a user wants to preview an Office attachment, Exchange/SharePoint/Lync makes a Web app Open Platform Interface [WOPI] call to the Office Web Apps Server which renders the document instead.

Note:
OWAS is not used to render attachments in IRM [Information Rights Management] protected messages.

Installing Office Web Apps Server

Although this article is about the integration of OWAS with Exchange 2013 and how to configure it, I will provide a basic guide on how to install OWAS on a single Windows Server 2012 box.

The first step is to install the prerequisite software for OWAS. To do this, open a PowerShell console as an administrator and run the following cmdlet and then restart the server:

Figure 3: Installing OWAS Requisites

Now, download Office Web Apps Server from the Microsoft Download Center. Double-click the .img file you just downloaded and run Setup to start the installation:

1. On the Read the Microsoft Software License Terms page, select I accept the terms of this agreement and then select Continue:

Figure 4: OWAS Installation — License Terms

1. On the Choose a file location page, select the folder where you want to install OWAS and then select Install Now (I left the default location):

Figure 5: OWAS Installation – File Location

1. When Setup finishes installing Office Web Apps Server, click on Close:

Figure 6: OWAS Installation – Complete

After installing Office Web Apps Server, you might notice that there is no GUI to manage it! This is because configuration and management of OWAS is done solely through PowerShell. Unlike products such as Exchange, Lync or even SCOM, OWAS only has a few cmdlets:

Figure 7: OWAS Cmdlets

Configure Office Web Apps Server

Now that Office Web Apps Server is installed, we need to configure it.

OWAS can communicate with SharePoint, Lync and Exchange using HTTPS by the means of a digital certificate. This is obviously highly recommended for production environments. In a test environment, however, you do not need to use HTTPS, but in this case Lync will not work.

If you want to use HTTPS, please note that the certificate used in the OWAS server must meet the following requirements:

• The certificate must come from a trusted Certificate Authority [CA] and include the fully qualified domain name of the Office Web Apps Server farm in the Subject Alternative Name field (and must not begin with an asterisk);
• The certificate must have an exportable private key;
• The Friendly name field must be unique within the Trusted Root Certificate Authorities store;

After obtaining an SSL certificate from your own or a 3rd-party CA (usually recommended if you plan to allow external access to your OWAS server) you have to import the certificate to the OWAS server (I used the Certificates MMC to request a certificate from my internal CA which automatically saves it into the local certificate store). However, don’t bind the certificate manually in IIS as this will be done automatically as we will see shortly.

Although we are installing OWAS in a single-server, we still need to create a farm. This is done using the New-OfficeWebAppsFarm cmdlet and the following parameters:

• –InternalURL is the FQDN name of the server that runs OWAS;
• –ExternalURL is the FQDN name so that OWAS can be accessed on the Internet;
• –CertificateName is the friendly name of the certificate to be used for HTTPS;
• –EditingEnabled (optional) enables editing in Office Web Apps when it is used together with SharePoint. It is not used by Lync or Exchange because these hosts do not support editing.

There are many additional parameters to configure a farm, which are not relevant for this article. To know more about these, run: Get-Help New-OfficeWebAppsFarm -Detailed

In my environment, I used the following cmdlet:

New-OfficeWebAppsFarm -InternalUrl “https://owas.letsexchange.com” –CertificateName “OfficeWebApps Certificate” –EditingEnabled

Figure 8: OWAS Configuration — New Farm

After the farm is created, we can see its details in the PowerShell window. To verify that OWAS is installed and configured correctly, use a web browser to navigate to the OWAS discovery URL, composed of the InternalUrl followed by /hosting/discovery. In my case:

If OWAS is working as expected, you will see a WOPI-discovery XML file in the web browser:

Figure 9: OWAS WOPI-discovery XML

Configure Office Web Apps Server Integration

Now that we know that OWAS is working fine, let’s configure Exchange 2013 to use it.

Configure Office Web Apps Server URL

To use OWAS to render attachments in OWA, first we need to specify the URL of the OWAS using the Set-OrganizationConfig cmdlet (this is done from an Exchange Management Shell):

Figure 10: Configuring OWAS URL

Note:
WAC stands for Web Access Components.

If everything went well, you will see the Application Log the 140 and 142 Event IDs for MSExchange OWA. 142 means the discovery of the Office Web Apps Server was successful, while a 141 means something went wrong:

Figure 11: OWAS Integration Configuration Event ID 140

Figure 12: OWAS Integration Configuration Event ID 142

Enable Office Web Apps Server Rendering

By default, the OWA Virtual Directory is already configured to enable the rendering of attachments through OWAS both on public and private computers:

Figure 13: OWA Virtual Directory Configuration

If you want to disable, for example, OWAS from being used on public computers, you can do so using the following cmdlet (this assuming OWAS is accessible from outside your internal network):

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -WacViewingOnPublicComputersEnabled $False

Force Office Web Apps Server Rendering

Another available option is to force users to render attachments using OWAS first before they can open them. As you guessed, this is done by setting ForceWacViewingFirstOnPublicComputers and/or ForceWacViewingFirstOnPrivateComputers to True.

Office Web Apps Server Logs

To determine where the Office Web Apps Logs are stored, run the following cmdlet in the OWAS PowerShell prompt:

Figure 14: OWAS Log Files Location

In that folder, which you can change, you will find OWAS log files. OWAS is very “verbose” so these logs contain a lot of information which makes them hard to go through. However, all the information is there.

Office Web Apps Server Document Preview

Once everything is working, we can preview Office documents the same way we do in Exchange 2007 and 2010: by clicking on the Preview link next to the attachment:

Figure 15: Document Preview in Exchange 2013

As you can see from the screenshot below, OWAS integration works in any of the “main” web browsers and the document preview itself is much more faithful to the actual document than with WebReady Document Viewing (compare this with Figure 2):

Figure 16: Document Preview in Exchange using OWAS

Conclusion

Integrating Office Web Apps Server with Exchange 2013 to preview Office attachments might be a security and user experience improvements, but it is still another piece of software that administrators have to consider, design and implement and maintain.

It would be interesting, and useful, if Microsoft allowed users to edit documents through OWA using OWAS as they do when using SharePoint. Maybe this will be available soon.

Office web apps server 2020

Что касается функционала демонстрации презентаций PowerPoint в ходе конференции Skype for business, пока что, разительно ничего не поменялось по сравнению с Lync 2013. Для этог так же используется сервер Office Web Apps. Информации об этом довольно много в сети, но все же опишу в отдельной статье как подружить Office Web Apps co Skype for Business Server 2015.

В первую очередь нужен отдельный сервер, который не является частью топологии S4B. В моем варианте будет использовать сяодин сервер, но можно использовать также пул серверов Office Web Apps.

Установка Office Web Apps

В первую очередь, надо подготовить сервер, установив на сервер предварительные роли и компоненты.

После установки сервер надо будет перезагрузить.

После этого нужно запустить установку Самого Office Web Apps Server 2013. В ноябре 2014 его изъяли из общего доступа. Так что теперь он доступен, только тем счастливчикам, кто успел скачать его заранее, ну и не менее счастливым обладателям Enterprise Agreement (даже для партнеров и то доступ закрыли). Вообще установка элементарная, итак, запустить Setup.exe с установочного дистрибутива. Сразу же предложат принять лицензионное соглашение

Далее выбор локации, куда все это установить.

Далее сам процесс установки и оповещение об успешном завершении с «благодарностью» от Майкрософт за установку их софта (будто есть варианты).

Далее небходимо установить обновление для Office Web Apps, которое, в отличие от установочного дистрибутива, находится об общем доступе, и веcит, к слову говоря, вдвое больше ☻. Скачать его можно отсюда https://support.microsoft.com/ru-ru/kb/2837634

Установка обновления также проста. Нужно принять, опять таки, лицензионное соглашение.

Ну а далее насладиться процессом установки в виде зеленеющей полоски прогресса.

ну и оповещением об успешном завершении.

Ну а тепереь об интересном.

Запрос сертификата

Естесственно, в первую очередь потребуется сертификат. Тем, у кого есть сторонний коммерческий сертификат с нужными SAN именем (я буду использовать WebApps), рекомендую использовать его, это самый лучший вариант. Тем же кому не хватает на это средств или навыков убеждения руководства, можно использовать мой вариант, тем более, что имя внутреннего и вненшнего домена совпадают.

Надо запросить сертификат в доменном центре сертификации. Для этого открыть mmc-консоль управления сертификатами и создать новый запрос.

Далее выбрать доменную политику

далее запросить сертификат в сообтветствие с запросом

Затем в свойствах выданного сертификата необходимо указать «Friendly Name» сертификата, оно будет использоваться в ферме Office Web Apps.

ну и убедиться, что понятное имя сертификата присутствует

(!)Этот вариант, возможно, мало кому подойдет, для запроса сертификата с набором SAN имен рекомендую использовать конструкторы запроса сертификатов S4B(Lync) или Exchange.

Далее можно приступить к созданию фермы.

Создание фермы Office Web Apps

Для этого нужно просто выполнить командлет PowerShell

New-OfficeWebAppsFarm -InternalURL «https://webapps.alekssh.com» -ExternalURL «https://webapps.alekssh.com» -EditingEnabled:$True -CertificateName WebApps

• https://webapps.alekssh.com — имя и внешнего и внутреннего адреса фермы. Внутренний будет использоваться в локальной сети, внешний при опубликованном доступе через интернет. Могут различаться.
• -EditingEnabled:$True — необходимо установить значение True, для того чтобы презентаци можно было редактировать.
• -CertificateName WebApps — friendly name сертификата, который будет использоваться в ферме. Этот сертификат должен располагаться в контейнере Личные сертификатов локального компьютера на сервере WebApps. Также в SAN имени должны быть указаны внутренние и внешние адреса фермы.

Далее, нужно убедиться что показ презентации PowerPoint работает в ходе конференции S4B. Вроде робит.

Вообще, конечно, весьма благодатная почва для полноценного траблшутинга 🙂 Скажу сразу, описанный вариант на недоменных машинах при попытке показа или просмотра презентации будет ошибка «При проверке сертификата сервера возникла проблема…», что в англоязычном варианте звучит как «There was a problem verifying the certificate from the server…»

решилось методом отключения проверки отзыва сертификата в IE.

Более подробный траблшутинг и описание проблемы в прекрасном блоге на технете

Особенности установки Office 2019 в корпоративной среде

Первое, с чем может столкнуться администратор при развертывании Office 2019 в компании – теперь нельзя скачать установочный образ Office 2019 на сайте лицензирования Volume Licensing Service Center (VLSC). Установочные файлы Office теперь доступы в Интернете в сети Office CDN (Content Delivery Network). Другая неожиданность, дистрибутив Office 2019 теперь поставляется не в виде привычного MSI пакета, а распространяется через установщик Click to Run (как и Office 365). В этой статье мы рассмотрим особенности подготовки и развертывания корпоративной версии Office 2019 в сети предприятия (вручную, с помощью GPO или SCCM).

Основные особенности Office 2019, о которых нужно помнить перед началом развертыванием пакета в компании:

1. Office 2019 можно установить только на Windows 10 или Windows Server 2016/2019;
2. Установщик Office 2019 основан на технологии «Нажми и работай / Click-to-Run (C2R)», а не на классическом MSI установщике (как это было в предыдущих версиях Office);
3. Нельзя одновременно использовать на компьютере Office 2019 и предыдущую версию Office или любой пакет из Office 365 (например, вы не сможете установить Skype for Business Click to Run из Office 365);
4. Для настройки параметров установки Office 2019 теперь используется Office Deployment Tool (ODT) вместо привычной Office Customization Tool (OCT);

Перед началом развертывания Office 2019, скопируйте из своего личного кабинета на сайте VLSC ключ для установки продуктов из комплекта Office (это может быть ключ для активации KMS сервера, или MAK ключ многократной установки).

Для развертывания Office 2019 по технологии Click-to-Run нужно использовать специальную утилиту – средство развёртывания Microsoft Office Deployment Tool – ODT (также он используется для развертывания Office 365 ProPlus).

Как вы видите, в каталоге установке есть три XML файла c образцом конфигурации установки: configuration-Office365-x64.xml, configuration-Office365-x86.xml и configuration-Office2019Enterprise.xml. Программа setup.exe используется для запуска получения дистрибутива и запуска установки пакета Office на клиенте.

В данном случае нас не интересуют файлы конфигурации для Office 365 (в чем отличия Office 2016/2019 от Office 365). Перейдем к рассмотрению XML файла configuration-Office2019Enterprise.xml в котором содержится пример конфигурации Office 2019 Enterprise для канала Volume License. Рассмотрим структуру XML файла:

Рассмотрим основные параметры:

• OfficeClientEdition=»64″ – установка 64 битной версии Office 2019;
• Channel=»PerpetualVL2019 – установка Office 2019 по системе корпоративного лицензирования (Volume License);
• — установка английской редакции Office. Для формирования и установки русской версии нужно указать ru-ru;
• —> — перед установкой Office 2019 необходимо удалить все старые версии Office, установленные через Windows MSI. Данный параметр закомментирован, но для перед развёртыванием Office 2019 его нужно включить, иначе вы столкнетесь с ошибками при развертывании;

— вы можете указать компоненты пакета Office (ProPlus2019Volume, Standard2019Volume, ProjectPro2019Volume, ProjectStd2019Volume, VisioPro2019Volume, VisioStd2019Volume), которые нужно установить. В параметре P > вы можете устанавливать только выбранные приложения Office (по умолчанию C2R установщик ставит все приложения пакета Office).

После того, как вы сформировали XML файл, вы можете скачать дистрибутив для установки Office 2019. Для этого выполите команду:
Setup.exe /download configuration-Office2019Enterprise.xml

Загрузка дистрибутива выполняется в тихом режиме. Для загрузки нужен доступ в Интернет, файлы загружаются из сети CDN Office.

После окончания загрузки в каталоге Microsoft Office Deployment Tool появится каталог Office (содержит cab и dat файлы для установки Office 2019) размером около 2 Гб.

Полученный пакет можно использовать для установки Office 2019 на компьютеры пользователей. Но, чтобы каждый компьютер не загружал установочные файлы Office 2019 из сети CDN, а пользовался локальной копией, нужно в XML файле указать путь к каталогу с файлами установки Office. Проще всего их разместить в общей сетевой папке. Например:

Для генерации XML файла для Office 2019 выберите:

• Office Suites: Office Standard 2019 – Volume License
• Update channel: Office 2019 Perpetual Enterprise

Так же вы можете указать, что установочный файлы Office нужно получать не из CDN сети Microsoft, а из сетевой папки внутри локальной сети.

После того, как вы заполнили все формы, нажмите Export, скачайте XML файл и поместите его в каталог с Office Deployment Tool.

Теперь вы можете скопировать каталог Microsoft Office Deployment Tool с xml файлами и дистрибутивом Office 2019 в сетевой каталог или на SCCM сервер.

Для начала установки Office2019 вам достаточно выполнить команду:

Setup.exe /configure configuration-Office2019Enterprise.xml

После окончания установки Office 2019 Enterprise или любого его пакета, вы можете активировать продукт с помощью MAK ключа многократной установки, если вы не указали его в XML файле (Файл -> Учетная запись -> Сведениями о продукте -> Изменить ключ продукта) или с помощь KMS сервера (как установить KMS сервер для активации Office 2019).

Для дальнейшей настройки параметров Office на компьютерах пользователей вы можете использовать административные шаблоны GPO.