Forum Widgets
Latest Discussions
Enterprise network insights and network score in the Microsoft 365 Admin Center
[Edit 9/21/2020: This post is about Ignite 2019. Ignite 2020 content for Office 365 network connectivity is at http://aka.ms/netignite] Today we are announcing a preview program for network insights and a network score in the Microsoft 365 Admin Center. The new network performance pages in the Microsoft 365 Admin Center show network insights and a network score for enterprise customers. Network insights are specific recommended network architecture design changes to improve user experience related to network connectivity to Office 365 and the network score shows how network connectivity impacts user experience allowing for comparison of different user location network connections. Enterprises using Office 365 with multiple office locations and non-trivial network perimeter architectures can benefit from this either during their initial onboarding to Office 365, or in order to remediate network performance issues discovered with usage growth. This is usually not necessary for small businesses using Office 365, or any enterprises who already have simple and direct network connectivity. Enterprises with over 500 users would be expected to benefit the most. You can register interest in the preview program which is planned to start in the first quarter of 2020 at http://aka.ms/netpreview. Enterprise network connectivity challenges Many enterprises have network perimeter configurations which have grown over time and are primarily designed to accommodate employee Internet web site access where most web sites are not known in advance and are untrusted. The prevailing and necessary focus is avoiding malware and fishing attacks from these unknown web sites. This network configuration strategy, while helpful for security purposes, can lead to degradation of Office 365 user performance and user experience. Enterprises can improve user experience but also continue to secure their environment by following Office 365 connectivity principles and soon by using the new Microsoft 365 Admin Center network performance feature. This feature helps with network architecture design that aligns with the Office 365 connectivity principles and should lead to optimized network performance for connectivity to Office 365. How we can solve these challenges Microsoft is often asked to investigate network performance issues with Office 365 for enterprise customers, and these frequently have a root cause related to the customers network egress infrastructure. When a common root cause of a customer network perimeter issue is found we seek to identify simple test measurements that identify it. A test with a measurement threshold that identifies a specific problem is valuable because we can test the same measurement at any location, tell whether this root cause is present there and share it as a network insight with the admin. Some network insights will merely indicate a problem that needs further investigation. A network insight where we have enough tests to show a specific remediation action to correct the root cause is listed as a recommended action. These network insights based on measurements past a predetermined threshold are much more valuable than general best practice advice since you do not have to ask whether certain best practice applies and will result in significant user experience improvement or not. Network performance in the Microsoft 365 Admin Center Microsoft has existing network measurements from included several Office desktop and web clients which support the operation of Office 365. These same measurements are now being used to provide network architecture design insights and a network performance score which are shown in the network performance page on the Microsoft 365 Admin Center. Approximate location information associated with the network measurements can identify the city where client devices are located. This is used to show the customers office locations and network measurements are grouped to provide network insights for that office location. On the screenshot example shown of the network performance overview page the customer has devices centered across five geographic locations. The network score at each location is shown with color and the relative number of users at each location is represented by the size of the circle. This overview page also shows the network score for the customer as a weighted average across all office locations. Specific office location network performance and insights Selecting an office location opens a location specific summary page. We show details of the network egress that has been identified from measurements for that office location. On the screenshot example of the office location summary page the office location in Philadelphia has network egress on the U.S. west coast, resulting in significant network cost and user experience impact. The page also shows a network score which indicates the relative user experience impact of network connectivity and allows for comparisons of network performance between locations or between different customers in the same city. The network score is calculated from measurements that impact user experience for key Office 365 workloads. It uses the TCP latency from the client to the Exchange Online service front door, the download speed for documents from the client to the SharePoint Online service front door, and the UDP latency, jitter, and packet loss from the client to the Microsoft Teams service front door. As network connectivity improvements are made, this score will increase along with user experience. The office location summary page additionally shows a network score history, a comparison of this locations score to other customers in the same city, and a list of specific insights and recommendations that the customer can undertake to improve their network connectivity. Comparisons between customers in the same city are based on the expectation that all customers have equal access to network service providers, telecommunications infrastructure, and nearby Microsoft network points of presence. The details tab on the office location page shows the specific measurement results that were used to come up with any insights, recommendations, and the network score. This is provided so that network engineers can validate the recommendations and factor in any constraints or specifics in their environment. For customers who want to improve the accuracy of office locations and recommendations provided we allow for more specific information to be entered. This is done by editing the discovered location information and can reduce the approximations that are inherent in the location information available for network measurements. Many of these tests and recommendations are available already in the Network Onboarding Tool proof of concept which you can use today. Network Performance in the Microsoft 365 Admin Center expands on this by showing insights across all office locations where the tenant is used, basing insights on existing measurements so that less on the ground office location specific testing is required, and adding a network score. The Network Performance page in the Microsoft 365 Admin Center is coming to customers in 2020 and we are planning to start a preview in the first quarter of 2020. You can register your interest in the preview by completing this form: http://aka.ms/netpreview You can watch the recorded demo session THR3085 online for a demo of Network Performance in the Microsoft 365 Admin Center. Also read about other Office 365 network connectivity innovation announcements.Office 365 Network Performance tool POC release
[Edit: A new version of the POC was published on 6/19/2019. Announced here: https://techcommunity.microsoft.com/t5/Office-365-Networking/Updated-Office-365-Network-Onboarding-Tool-POC-with-new-network/m-p/711130#M130] [Edit: We updated the POC on 3/29/2019. Original post was on 1/16/2019] With the size and scope of Office 365, a deployment can represent significant impact on an enterprise network. Connectivity issues can be complex and there are a variety of aspects to optimize including latency, local egress, WAN routing, open firewall ports, proxy bypass, bandwidth, DNS, DLP devices, cloud security brokers, etc. Published today, a new Office 365 Network Performance POC tool is intended to help Office 365 enterprise customers with network connectivity related testing and connectivity guidance. Our goal is to provide a tool that runs sufficient networking tests that we can provide detailed guidance containing network configuration recommendations about devices between user machines and Microsoft’s network. The scope for this includes connectivity for all applications and services in Office 365 and spanning the customers LAN and WAN, proxy servers, firewalls, other perimeter network devices, ISP connectivity, cloud security brokers, and network routing up to Microsoft’s network. Whilst we have network onboarding guidance to help with this published here, we think that by running network tests at each of your user locations we will be able to provide customized guidance that makes this work easier. It can be difficult to know what changes will make the best improvements in performance for users. Per customer guidance based on specific testing can quantify this and inform you of what connectivity elements are working well, and what still needs work for optimal performance. This should help customers doing network onboarding to have confidence in choices about networking improvements. We’re starting small and have released a proof of concept tool to begin this project. It runs only a subset of the tests we are planning. It focuses on the network distance between user locations and Office 365 service front door servers. It identifies the following locations: Your location either from your web browser, or that you type in Your network egress location The Office 365 service front door server location you are using The optimal Office 365 service front door location for users in your city or metro area From these locations we can provide advice if the optimal Office 365 service front door location is significantly distant to the one you are using now. We also provide a comparison of your Office 365 performance to other users in your city of metro area. Whilst this work is focused at network onboarding for Office 365, it can also help with troubleshooting and optimization. If you want to improve the performance that your Office 365 users are seeing there may be optimizations you can make in your network connectivity. Also, some Office 365 customers don’t focus on network connectivity with they first start using Office 365. If you’re working with a customer that has performance issues or features in Office 365 that aren’t working, it could be that they haven’t completed network connectivity onboarding. Please try it out and share your feedback as a reply below. We’re looking for feedback and we will be adding tests and guidance to this tool over the coming months. http://aka.ms/netonboardUse Microsoft Flow to receive an email for changes to Office 365 IP Addresses and URLs
[Edit 4/16/2019: I've rewritten this article, please take a look here: https://github.com/pandrew1/Office365-IPURL-Samples/tree/master/FlowNotifications] If you manage an enterprise network that uses Office 365 you are probably familiar with Office 365 IP Addresses and URLs you probably also know that there are updates to these about once a month. This article demonstrates how you can use Microsoft Flow to alert you with an email whenever there are changes to the Office 365 IP Addresses or URLs. The flow will fetch the latest version of Office 365 network endpoints once an hour and it will compare that with the previous one that you have seen. The previous version that you have seen is stored in a SharePoint Online list on your Office 365 tenant. You will need to have an Office 365 tenant and the ability to create a SharePoint list that you have read/write access to. The Flow created in this article is not supported by Microsoft and you should follow your own development review processes before relying on it in a production environment. If you make improvements to this Flow, we would like to hear from you. Let us know in the comments below. Step 1 – Create a SharePoint list for the project Figure 1 - An example empty SharePoint Online site Figure 1 shows an example empty SharePoint Online site. Click the Lists menu item in the left navigation menu, then click “New”, and select “List” to create a new list. Figure 2 - Create a new list We will call the new list Endpoints so type that in the Name field. Figure 3 - Create list form Figure 4 - New list created for the local data Add text columns by clicking the “Add column” button for Latest (Single line of text), Endpoints (Multiple lines of text), and Previous (Single line of text). Figure 5 - New columns You will also want to make the ID column visible. Do this select All Items at the top right and select Edit view. Check the box next to the ID field and select OK. Figure 6 - Making the ID column visible in the view Add a seed item for the Flow to read. Add the “title” as “Worldwide” and add the “Latest” as “0000000000”. Other fields are not required. Save this and you’re now ready to create the flow that references this list. Keep a Web Browser tab open with this list. You will need the URL for it later. Figure 7 - Creating a seed item for the list Step 2 – Sign up for Microsoft Flow Flow requires sign-up. I’ve only used free elements in Flow for this. You can read about the sign-up process and the free and paid plans at https://docs.microsoft.com/en-us/flow/sign-up-sign-in Once you’ve signed up you can go to flow at https://flow.microsoft.com Step 3 – Create a flow At the flow home page, select My Flows from the top menu. It takes you to https://flow.microsoft.com/manage/flows. On the My Flows page you can select Create from blank to create your flow. Figure 8 - Create from blank command Step 4 – Add the trigger A trigger starts your flow executing. We’re going to check the version of the Office 365 network endpoints once an hour, so our trigger is going to be a schedule. Figure 9 - Search triggers command Click on the search command and you should see the schedule trigger. If you don’t see it, you can type “Schedule” into the search box. Configure the schedule trigger to run once an hour. Then click the New step command and choose Add an action. Figure 10 - Configured schedule trigger Step 5 – Add the first command and configure it The first command is to get the last version of the network endpoints data that we saw from your SharePoint Online list. Figure 11 - Searching for SharePoint - Get items This command needs configuration. Enter the site address where the SharePoint list that you created earlier is located. You will need to authenticate to your Office 365 subscription for that. You may be able to select your SharePoint site from the drop-down list once you are authenticated. Then add the name of the list. Figure 12 shows the SharePoint list that I am using which you will not have access to. Figure 12 - Configuration for SharePoint Online list Step 6 – Add the command to check Office 365 network endpoint data version Click the New step button under your Get items action and select Add an Action again. Type HTTP and select HTTP – HTTP from the list of action search results as shown in Figure 13. Figure 13 - Search results for HTTP action Configuration of this action is really simple. Select the GET method and enter the Uri for the endpoints version web method as shown in Figure 14. You can use any GUID as the ClientRequestId or copy the one in the figure. Test the Uri in a web browser before you put it into the Flow. In the web browser you should see a result that has the same format as in Figure 15. Keep this web browser window open as we will refer to it later. Figure 14 - Configured HTTP action Figure 15 - Example web service call in Web Browser Step 7 – Add a command to apply schema to the JSON output This next command is required to identify the output of the web service request as JSON by providing the data structure that is used. Click Add action and enter “Parse JSON” in the search field. You should see the action in the search results. Figure 16 - Parse JSON action The Parse JSON action requires two fields to be entered. The Content field will be the first dynamic content field that you enter. To do this you click in the Content field and the Dynamic content window will appear. You just have to click Body in the HTTP section of this and you will see Body appear in the Content field. There’s more to these fields as we’ll see later, but this one is that easy. Figure 17 - After selecting the HTTP Body content item Next you will enter the schema. You can enter the schema directly, but it’s easier to have Flow generate it. Click “Use sample payload to generate schema” and you’ll see a popup. Go back to the browser window you had open in Figure 15. Figure 18 - Right click on selected web service output Copy the output and paste it into the Flow “Enter or paste a sample JSON payload” window. You should see the schema generated as in Figure 19. Figure 19 - Configured Parse JSON action Step 8 – Compare the current version to the SharePoint list item(s) The SharePoint list may return multiple items so we need to figure which one we are working with. To simplify this, we will just compare the latest version with all of the SharePoint items. This is done by adding the “Apply to each” action. Figure 20 - adding the apply to each action The Apply to each action requires configuration and Dynamic content makes this pretty easy. Only one item shows up and it’s the right one. Click the “value, List of Items” content in the Dynamic content pane to select it for the Apply to each configuration. Figure 21 - Configured Apply to each action The “Apply to each” works like a loop. We’re going to add a condition inside of it next and that condition will get executed for every result. There will typically only be one item in the SharePoint list. Step 9 – Add the comparison condition Click Add a condition within the Apply to each action. You should see Figure 22 Figure 22 - Adding a new condition to the Apply to each To configure the condition, we have to setup the three fields. Click within the left field and the Dynamic content pane will appear with lots of items. Scroll down to the section titled “Get items” and find the SharePoint item column called Latest. If this doesn’t appear then you may not have added it to the SharePoint list configuration so go back and add that. Figure 23 - Choosing the Latest column from your SharePoint list Next choose “contains” in the second field as the condition. And then click in the third field to bring up the Dynamic content window again. This time we will select “latest” from the Parse JSON section. Figure 24 - The third field in the condition You’ve now created a condition that compares the version of the endpoint data that you have in your SharePoint Online list with the version of the endpoint data that you just got from the web service. If these are the same, then the Flow can exit. This is the Green path labelled “If yes”. If these are not the same, then we have more work and we will add some more actions to the Red path labelled “If no”. Figure 25 shows what it will look like when you’re complete. Walking through these one by one: Get the latest endpoints data Get the changes since last time you got an update Create an email and attach the two outputs of the latest endpoints data and the changes Add a new item to the SharePoint Online list to represent the new latest version Delete the old latest item from the SharePoint list. You can omit this and keep all the old versions if you choose Figure 25 - Completed "If no" path in the condition Step 10 – Add the two HTTP GET actions Click Add an action within the Red path that is labelled “If no”. Type HTTP and select the HTTP – HTTP action. Configure this action as GET, and with the Uri for getting the latest endpoints data. Again, you can test the Uri in a web browser. This is the Uri: https://endpoints.office.com/endpoints/worldwide?clientrequestid=b10c5ed1-bad1-445f-b386-b919946339a7 Click Add an action underneath the HTTP 2 action that you just added and add another one in the same way. Configure this one as GET also. The Uri for this one is a little more complicated. Here’s a Uri you can test in a web browser which has the latest version listed as 0000000000: https://endpoints.office.com/changes/worldwide/0000000000?clientrequestid=b10c5ed1-bad1-445f-b386-b919946339a8 We’re going to use that, but the previous version will come from your SharePoint Online list instead of being 0000000000. Add this text to the Uri field: https://endpoints.office.com/changes/worldwide/ With the field still selected and the cursor at the end of that text make sure that the Dynamic content window it is showing. If it isn’t then you will need to click on “Add dynamic content”. Scroll to the “Get items” section and click “see more” to show all the columns from the SharePoint Online list and select “Latest”. We are going to use the latest attribute to provide a parameter to the changes web service so that we see all of the changes since that version. This is what you want to review and apply to your network perimeter devices since the last update you took. Once you click Latest, you should see the action configured as in Figure 26. Figure 26 - The parameter for the changes web service To complete the Uri, we need to add the clientrequestid parameter. You can just click in the field after the Latest tag and type or paste the extra text in. ?clientrequestid=b10c5ed1-bad1-445f-b386-b919946339a8 Once you’ve done that you should have two GET actions that look like this with parameters. If you get the “Enter a valid uri” error you need to fix this. I fixed this by selecting the URL and using CTRL-X and CTRL-V. You can also test the Uri in a web browser. Figure 27 - Two configured HTTP GET actions for fetching endpoint data Step 11 – Sending an email or getting a review and approval on the updates We’re going to add a “Send an email” action to the flow next. You could alternatively use an approval request action here and have the changes reviewed before being sent out if that’s required in your process for these updates. Click “Add an action” underneath the HTTP 3 action. Search for “Send an email” and add it to the flow. This action is in the “Office 365 Outlook” connector and will likely be the first search result. Fill in the To, Subject, and Body fields to be whatever you want. You can use fields from the Dynamic content window in these also. Click advanced options so that we can add the attachments. Also, you can set a From address which either needs to be an account that you have Send as permissions on, or a Distribution List that you are the owner of. Click “Add new item” to add a second attachment and configure both as shown in Figure 28. You can see that some of the text is typed into the field and some is from the Dynamic content generator similar to the HTTP 3 GET action. The four Dynamic content items in order are: Get items -> Latest HTTP 3 -> Body Parse JSON -> latest HTTP 2 -> Body Figure 28 - Configured Send an email action The email will have two attachments with contextual filenames where the first contains the data from the web service listing the most recent changes and the second contains all the network endpoints data. To help debug these fields you can hover over the Dynamic content fields and see the code behind them. This shows which flow activity the content came from and the field on that flow activity. This text is also shown in the JSON downloadable version of the flow. Step 12 – Cleaning up the SharePoint Online list In this step we will add the new latest seen version to the SharePoint list and delete the old item. We will add an action called “Create item” which is in the SharePoint connector. Search for it by typing “Create item” in the search box. Enter your SharePoint Online site address and select your list name. Once the list is selected you should see the columns appear from your list and we will populate several of these from Dynamic content. If the column names don’t appear, check that they are included in the list on your SharePoint Online site. Title: select Dynamic content Parse JSON -> Instance Latest: select Dynamic content Parse JSON -> latest Endpoints: select Dynamic content HTTP 2 -> Body Previous: select Dynamic content Apply to each -> Latest Figure 29 - Configured Create item action Add another action and search for “Delete item” in the SharePoint connector. Enter the same SharePoint Online list site address and list name as before. The Id can be found in the Dynamic content window in the “Apply to each” section. For some reason it was missing when I did this. You don’t want to choose the Id column from the Create item action because that would delete the item you just created. If it’s not in the Apply to each section you can add it manually by opening the Dynamic content window, and selecting the Expression tab. Next enter this as the expression text. Items('Apply_to_each')['Id'] Figure 30 - Configured Delete item action Step 13 – Save and Test You can now save and test the Flow directly on the editing window. After you click Test you will see this question. Select “I’ll perform the trigger action”. Figure 31 - Testing the flow Figure 32 - Running the flow After the flow has run, you can review the execution steps. Figure 33 shows a run where no new version was detected. Figure 34 shows a Flow run where a new version was detected, and the email was sent. To pretend that a new version has been detected you can simply edit the list item on SharePoint Online and set the previous version to something old such as 2017010100. Then run the flow and it will think there’s a new version on the web service so that you can test the “If no” path. Figure 33 - Execution steps for the Flow Figure 34 - Successful Flow run where a new version was detected Summary You could extend this Flow with approvals as needed and forward the changes to your team who manages network perimeter updates.Office 365 Network Onboarding tool POC updated with VPN testing
Today we’re announcing an update to the Office 365 network onboarding tool. It now detects use of a VPN and evaluates if the VPN is configured for recommended Office 365 split tunneling. With many companies sending employees to work from home scalable and performant VPN implementation supporting Office 365 is one of the top responsibilities that IT faces. Office 365 split tunneling guidance is documented at http://aka.ms/o365vpn. The Office 365 network onboarding tool shows VPN results after the advanced test client is run. You should click the Run Tests button to download it and a Windows PC is required. The advanced test client has the filename format Connectivity.[guid].exe and it is digitally signed by Microsoft Corporation. It is 2.3 Mb and the prerequisite .NET Core runtime for x64 is 51.9 Mb. VPN results show in two lines in the Details and solutions tab. These do not appear if you have not run the advanced test client. The first line identifies if a VPN is in use on the local machine and attempts to identify the name. It shows a red cross if forced tunneling is detected on the VPN. The second line evaluates Office 365 optimize category IP Address ranges and how they are routed. Forced tunnel routing means that all of the optimize category IP Addresses for a workload are sent to the VPN tunnel Split tunnel routing means that none of the optimize category IP Addresses for a workload are sent to the VPN tunnel. This is the recommended configuration Selective tunnel routing means that some but not all of the optimize category IP Addresses for a workload are split out as recommended. A description of the optimize category network endpoints can be found at http://aka.ms/pnc. IP Addresses included in the optimize category can be found at http://aka.ms/o365ip. Note that VPN route evaluation is for the Office 365 worldwide commercial instance only. No evaluation is done for other Office 365 service instances. For this release we have also redesigned the advanced test client installer. It now uses .NET core 3.1.3 desktop runtime or later. If the pre-requisite runtime is not installed, then the user will be linked to the install web page and the user has to install it before they can run the test client. https://dotnet.microsoft.com/download/dotnet-core/current/runtime You must install the .NET Core Desktop Runtime. The PC installers are highlighted in this snippet from the web page. Documentation for the tool is here: https://docs.microsoft.com/Office365/Enterprise/office-365-network-mac-perf-onboarding-tool FAQ Q. How can I use this to troubleshoot a user’s home internet connectivity for use with Office 365? A. Ask the user to run the tool and the advanced test client at home and to send you the output. Evaluate the output to find things that could be improved.New Office 365 IP/URL tables published
Microsoft has IP Address and URL information for Office 365 in a variety of formats including HTML tables, XML download file, RSS feed, and others. The data is needed in scripts and network devices and that is best served by web services rather than web pages and we're working on a larger project to validate and publish this data through web services. We're replacing these publishing points and focusing on REST based web services. It will continue to be possible to get HTML and RSS formats of the data. We are adding attributes to the web services output including a required attribute, an ExpressRoute attribute, and a network endpoint criticality category attribute. All of this is expected to result in simpler and faster network connectivity onboarding for Office 365 and fewer customer concerns with the data. This project is described at http://aka.ms/ipurlblog. As a part of this project on Tuesday August 21st, 2018 we migrated the HTML tables of IP Addresses and URLs for Office 365 to a new publishing platform. The new pages are generated from our web services automatically and look a little different to the old ones. Any links to the old pages will automatically redirect to the new ones. FAQ on the new IP Address and URL page publishing: What pages are being migrated? http://aka.ms/o365ip - Office 365 worldwide commercial IP Addresses and URLs. https://aka.ms/usip - Office 365 GCC High IP Addresses and URLs. https://aka.ms/usdodip - Office 365 US DoD IP Addresses and URLs. https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges-21vianet - Office 365 operated by 21Vianet IP Addresses and URLs. https://docs.microsoft.com/en-us/office365/enterprise/office-365-germany-endpoints - Office 365 Germany IP Addresses and URLs. A separate Office 365 ProPlus IP Address and URL page was merged into the Worldwide Commercial IP Addresses and URLs page. What is this data used for? Office 365 enterprise customers who have multiple office locations commonly have wide area networks connecting those office locations and perimeter networks that control and secure Internet connectivity. Office 365 requires favorable network connectivity and we publish IP Addresses for customers to use as ACL lists in their firewalls and we publish URLs for customers to use for security device bypass in proxy servers. Many customers automate the update of their devices from this data and load the changes every month. Where does the new generated table date come from? They are generated from IP/URL web services as described at http://aka.ms/ipurlblog Did the IP/URL endpoint data change with this new publishing? The data is the same. We have been publishing changes to the support.office.com pages from the web services for the past several months in preparation for this change. What notice was provided about these changes? The blog post describing these changes was first published on April 1 st . Customers have been notified of the change in Message Center post MC133236. Where are the detailed descriptions of URLs and IP Addresses from the previous published page? We are working to simplify the publishing to just what is required to configure network perimeter devices. As such many of the network endpoints can be now directed to default Internet egress locations. Detail about endpoints that are in the “Optimize” and "Allow" categories and require special networking consideration is available for customers who need this under NDA. The mapping of the old product list to the new service areas is listed in our migration article here: https://techcommunity.microsoft.com/t5/Office-365-Networking/Migrating-to-the-new-web-services-based-publishing-for-Office/m-p/229144#M26 What other IP/URL publishing is changing? The XML data files will be deprecated on October 2nd. The RSS feeds will be replaced with a new RSS feed and the current one will be discontinued. How can I find out details about a specific IP Address or URL used by Office 365? You can search in the new web pages or search the output of the web services with your own script. When will the new web services be out of preview and officially supported by Microsoft? The data published is production data and we are treating any schema or interface changes as production breaking so you can start working with the web services now. We are still working on production support and GA for the web services which is coming within a couple of months and will be prior to October 2 nd . Regards, Paul @pndrwStandard deployment configurations for Office deployment now available
Do you need to customize your Office deployment, or do you need to deploy a standard configuration? Maybe you just need to add Visio to an existing deployment? A new feature is now available in the Office Customization Tool for Click-to-Run that allows you to access preconfigured Office deployment configurations that can be used with the Office Deployment Tool. When you sign into the Office Customization Tool for Click-to-Run you will see an updated experience that allows you to access standard configurations for Office deployment as well as the set of customized Office deployment configurations that you may have created or uploaded. The list of standard Office deployment configurations includes 64bit and 32bit configurations for Office 365 ProPlus on Semi-annual channel and Monthly Channel as well as configurations that utilize intelligent matching features to simplify adding Visio and/or Project to a device that already have Office 365 ProPlus installed. In addition to these configurations we have also included a configuration that allows you to uninstall MSI and C2R based Office installations in situations where you need to start with a clean install or troubleshooting a deployment issue. To get started, sign in as an admin at https://config.office.com/. When you navigate to the Device Configuration page you will see the ‘Standard configurations’ tab by default. Simply choose one of the configurations and click the ‘Download’ or ‘Get Link’ button. If you download the XML, you can reference it on the command line using the local or UNC path. If you get the link you can simple call setup.exe with the desired action and reference the URL on the command line, i.e. setup.exe /configure "https://go.microsoft.com/fwlink/?linkid=2100547" (note the use of “ “ to reference the URL). For more information on using the Office deployment tool refer to the documentation published here. Important – please ensure you have downloaded the latest version of the Office Deployment Tool If you have any feedback feel free to comment on this post or go to https://config.office.com and use the feedback button.Hybrid deployment in Office 365 | Checklist and pre requirements
In the current article, we will review: The pre-requirements of Exchange hybrid environment Best practices and recommendation for the required preparations Tools and methods that will help us to check and verify if the on-Premises environment was configured correctly. The term Hybrid configuration or a Hybrid environment, describe a scenario in which two separated Exchange organizations that belong to different Active Directory forests are working as a “one unit”. The term Hybrid configuration was created, for describing this type of relationship between the Exchange On-Premise infrastructure and the cloud (Exchange Online) infrastructure. For example, in the following diagram, we see the logical concept of Hybrid environment. The Public Domain name: o365info.com, configured as a “shared Domain”. The meaning is that two separate Exchange infrastructure “represent” this domain name or shared between them the same domain name. When looking at the diagram, we can see two recipients: Bob@o365info.com andAlice@o365info.com Technically, the recipient mailboxes must be configured on the Exchange on-Premises server or at the Exchange Online server, but logically, Bob and Alice don’t know where their mailboxes hosted. In case that Bob mailbox is hosted on the Exchange on-Premises server and Alice’s mailbox is hosted on an Exchange Online server, Bob and Alice will have all the standard Exchange services such as: Free\Busy time, mail tips and more as if they are hosted in the same Exchange organization. The reason is that the Hybrid environment, “connect” the two distinct Exchange environments and making them appear as one entity. Hybrid configuration relationships and Trust concept As mentioned before, the Hybrid configuration was designed for “connecting” two different Exchange environments and make them operate as one entity. A trust concept implements the “glow” between the two distinct environments. Federation trust – each of the Exchange environments (on-Premises + cloud) needs or must trust a “third element” named: MFG – Microsoft’s federation gateway (number 1 in the diagram). Exchange organization relationships – a trust model between two separate Exchange organizations. In Hybrid environment, the Exchange organization relationship is implemented between the Exchange on-Premises forest and the “Office 365 forest” (Exchange Online) (number 2 in the diagram). The Hybrid configuration and the “Trust model” enable each of the “end points” (Exchange on-Premises and Exchange Online) to: Authenticate each other Verify the identity of each other Create a secure communication channel: Encrypt the information and implement data integrity by using a public certificate and by using a secure communication protocol such as SMTP\TLS and HTTPS. Simple Exchange on-Premises environment versus complicated environment. The term “Hybrid configuration” could use in describing a very simple scenario in which the organization has only one Exchange on-Premises server, who serves as a Hybrid server and is responsible for creating the “communication channel” between the on-Premises environment and the “cloud” (Exchange Online). Another scenario of Hybrid configuration could be a more complicated scenario, which is more common in enterprise environments that have complicated Exchange on-Premises infrastructure. In this scenario, the “relationship” between the Exchange Online and the “on-Premises Exchange infrastructure” could be divided into many “communication channels” with different\separated Exchange on-Premises servers. For example – the mail flow between Exchange on-Premises and Exchange Online could be implemented by using a “dedicated” Exchange on-Premises server which will be configured for sending mail to Exchange Online and, other Exchange on-Premises server which will be configured to “accept” mail from Exchange Online. Another Exchange on-Premises server could assign to different roles\services such as dedicated Exchange on-Premises server who will provide AutoDiscover services, dedicated Exchange on-Premises server who will provide EWS services and so on. Pre-requirements for Hybrid deployment in Office 365 In the next sections, we will review each of the components that includes in the “Pre-requirements for Hybrid environment list.” 1. Exchange Hybrid Server Version The term “Exchange Hybrid server” is just a logical term that describes Microsoft Exchange server which can be a part of a Hybrid environment. Note – the Hybrid environment based on two different “end point” such as Exchange on-Premises environment and the “cloud” (Exchange Online) environment. At the current time, the “cloud side” of the Hybrid configuration is based on Exchange 2013 SP1 technology. The Exchange on-Premises server “Hybrid server” could be implemented by using: Exchange 2010 SP3 Exchange 2013 Exchange 2016 Exchange 2010 SP3 as Hybrid server In case that we want to use an Exchange 2010 as a Hybrid server, the minimum requirement is service pack 3. Besides of the requirement for Service Pack 3, the best practice is: to install the most updated Exchange Rollup versions because each of the software updates (Exchange Rollup) includes a solution to issues\problem that was discovered and the fixed is included in the Rollups. Many times the customer or the organization IT will “resist” to the recommendation of “installing the most updated Exchange rollup“ but, it’s important to emphasize that installing the most updated Rollups can prevent many of the future problems and consider as an important factor in the process of building the Hybrid environment. The following quotation relates to Rollups 4 for Exchange 2010 SP3, but you get the idea. Additionally, we recommend installing future Update Rollups 4 for Exchange 2010 SP3 on all your hybrid servers. Microsoft releases update rollup packages approximately every six to eight weeks. The rollup packages are available via Microsoft Update and the Microsoft Download Center. In the Search box on the Microsoft Download Center, type “Exchange 2010 SP3 updates rollup” to find links to the rollup packages for Exchange 2010 SP3. [Source of information: http://technet.microsoft.com/en-us/library/hh945197(v=exchg.141).aspx ] Download link for the required Exchange on-Premises server software updates Exchange 2010 | How can I know what is the current Exchange Rollup? In case that you want to get information about the existing status of the Exchange 2010 on-Premises server, you can view the current version by using the Help menu and click on the About Exchange server 2010. In the following screenshot, we can see that the Exchange on-Premises server version is:14.03.0.195.001 So the next question could be: how can I know what is the Exchange on-Premises server service pack or rollup version based on this number? To be able to “translate” the value to a clearer information, we can use the article: http://social.technet.microsoft.com/wiki/contents/articles/240.exchange-server-and-update-rollups-build-numbers.aspx In the following screenshot, we can see that the version number: 14.3.195.1 is “telling” us that the Exchange 2010 on-Premises server includes an installation of Service Pack 3 + Rollup 6 for Exchange 2010 SP3. In this case, we will need to download and install to most updated Rollup (for example Rollup 9) The Cumulative Update (CU), Rollup, and Service Packs you have running on the on-premises server should also not be overlooked. Under normal circumstances we support you being no more than two updates behind the currently released update for Exchange; however, for hybrid environments, we are stricter, and you should not be more than one build behind. If the latest update is Exchange 2013 CU9, then you must have either Exchange 2013 CU9 or CU8 to be considered in a supported state. We are stricter with our hybrid requirements because of how tightly the on-premises and Exchange Online environments will be coupled together. For more information on our available updates please go https://technet.microsoft.com/en-us/library/Hh135098(v=EXCHG.150).aspx. [Source of information – http://blogs.technet.com/b/exchange/archive/2015/08/10/hybrid-deployment-best-practices.aspx] New Hybrid server versus existing Exchange On-Premise In case that the organization Exchange infrastructure based on older versions of Exchange such as Exchange 2003, 2007, we will need to “add” or install a new Exchange on-Premises server (2010 SP3 or 2013) that will serve as the “Hybrid server.” The “New” Exchange On-Premise Hybrid server can implement as Exchange 2010 or Exchange 2013 or Exchange 2016 but, the best practice is to install Exchange 2016 server instead Exchange 2013 or 2010 because Exchange 2016 includes improving features that relate to the Hybrid environment. You can read more information about the improvement in Exchange On-Premise 2016: Exchange Server 2016 Hybrid Perks Microsoft released its Exchange Server 2016 product https://redmondmag.com/articles/2015/10/01/exchange-server-2016-released.aspx. While the new product is an Exchange Server 2013 facelift of sorts, it was built based on Microsoft's Exchange Online service. Exchange Server 2016 has improved backend search and e-discovery capabilities, plus improved Outlook client support, among other features. It has other hybrid support benefits, according to a Microsoft TechNet library article updated in late January. Those benefits include: Secure e-mail routing between the two instances Use of a "shared domain namespace" for messages A shared address book (also known as "a unified global address list") Calendar sharing Mailbox mobility Centralized management via the Exchange Admin Center 2. Exchange On-Premise Hybrid Server | Public IP Address And Public Name (FQDN) Hybrid configuration is all about enabling Exchange On-Premise server which is configured as “Hybrid server” to create a communication channel with the Exchange Online infrastructure that exists in a public network. To be able to communicate hosts or “endpoint” on a Public network, the Exchange Hybrid server must have: Public Name – The public name of the Exchange Hybrid server should be published in the Public DNS and should resolve to the Public IP of the Exchange Hybrid server. Public IP address – A Public IP address that “Point” to the Exchange Hybrid server should be assigned. Most of the time, the Public IP address will not directly attach to the Exchange on-Premises server, but instead, the Public IP will be allocated to a Firewall server. Th eFirewall will accept the communication requests to the Exchange on-Premises server and forward the request to the internal IP address of the Exchange on-Premises server. Note – In case that we use more complicated scenario in which the on-Premises environment is “represented” by more than one Exchange on-Premises server, each of the Exchange On-Premise servers will need to have a dedicated Public IP. For example, in case that the Outbound mail flow based on two Exchange on-Premises servers who can send mail to the Exchange Online server, each of this server will need to have a dedicated Public IP address. How can I know what is the Public name of the Exchange On-Premise? The simple answer is that if you are the Exchange On-Premise Administrator, you supposed to know what the Exchange On-Premise public name is but, in some scenarios, we will have to configure and hybrid deployment in an environment which we are not familiar with. One option to get information about the “Public name” of the Exchange On-Premise server is by looking at the “External URL” that appears in the “client access” section under server configuration in the Exchange MMC (when we use Exchange 2010 MMC). In the following example, we will look under the “Server configuration\Client access\EX01” Exchange server “publish a ” couple of services. In our example, we look at the ECP tab (the ECP tab includes the Internal + External URL of the Exchange server using the web management interface). We can see that the “pubic name” (External URL) of the Exchange On-Premise is:mail.o365info.com Note – the External URL information includes parts that are only relevant for the URL syntax. Part of the URL is the host FQDN (Fully Qualified Domain Name). In our scenario, we are looking only for the Public Exchange server name (mail.o365info.com). Verify that the Exchange Hybrid Server Public name (FQDN) is mapped to his Public IP The verification process of the Exchange On-Premise Public IP is very simple. Open the command prompt and Ping the Public name of the Exchange On-Premise server. In our example, the Exchange On-Premise public name is: mail.o365info.com In the following screenshot, we can see that we got as an “answer” the public IP of the Exchange On-Premise server. One of the most common misconceptions is – that there is a problem because we got a “Request timed out”. This response is not a sign of a problem because, the host whom we “ping” (Exchange On-Premise in our scenario), was not supposed to reply to the ping request. This is a foreseeable result because most of the time the organization Firewall blocks the ICMP protocol (that used for the Ping reply). To recap: the fact that we got a response the Public IP is the required results, meaning the Exchange on-Premises server have a public name + Public IP address. Note – besides of verifying the Exchange Hybrid server public name and Public IP; we will need to check additional parameters such as the ability to access the Exchange Hybrid server using a particular protocol and so on. In the next sections, we will review these other requirements 3. Exchange On-Premise Hybrid Server | Port Number And Protocols Hybrid configuration based on sharing data and services between Exchange Online and Exchange on-Premises server. The communication channel implemented by using two communications protocols: HTTPS – access to the Exchange services (from Exchange on-Premises server to Exchange Online and vice versa) implemented by using the HTTPS protocol. SMTP – the SMTP protocol used for implementing mail flow, and the data is encrypted using TLS (TLS over SMTP). The underlying assumption is that – the Exchange on-Premises server protected by a Firewall. To be able to implement the communication channel, between the Exchange on-Premises server and the Exchange Online successfully, we will need to verify that the Firewall includes the following inbound and outbound rules: The inbound rule that enables to access the Exchange on-Premises server using port 25 (SMTP) and 443 (HTTPS). The outbound rule that enables the Exchange on-Premises server to access Exchange Online using the port 25 (SMTP) and 443 (HTTPS). Reference from Microsoft article The following screenshot is taken from a Microsoft article and includes a table the describe the port number and the services that need to enabled for Hybrid configuration 4. Exchange On-Premise Hybrid Server| Public IP Address And Static NAT An important factor that we need to verify is that the Exchange on-Premises server is using the public IP address that was assigned to him when he responds to a communication request of external hosts or when he initializes a connection to an external host. The technical term for this scenario could be as a “two-way static NAT”. For example: when using the Exchange 2010 Hybrid configuration wizard, we need to provide the public IP of the Exchange on-Premises server which is “allowed” to send an E-mail to the Exchange Online server. When the Exchange on-Premises server communicates the Exchange Online, it is important that the Exchange on-Premises server use the public IP that configured in the Exchange hybrid wizard. Other examples could be when the Exchange Online starts a communication process to the public IP of the Exchange on-Premises server. In this case, the Exchange Online server is “waiting” for a response from the IP address that used for starting the communication channel. An example for the static NAT rule could be: n the following diagram, we can see an example of static NAT rule. When external hosts such as Exchange Online try to communicate with the Public IP of the Exchange On-Premise server, the “response” from the Exchange on-Premises server implemented by using the same public IP address that we use for “publishing” the Exchange on-Premises server. 5. ISA-TMG Server And A Firewall Server When using ISA\TMG server to publish an Exchange On-Premise server, the configurations are a little bit different compares to a “standard Firewall” because, ISA\TMG is a Proxy server and additionally, Firewall server. When using a “Standard Firewall,” we redirect the communication to the internal Exchange On-Premise server by using a simple “access rule”. When using ISA\TMG Firewall, redirection to the internal Exchange On-Premise server is implemented by using a: Web publishing rule. The ISA\TMG web publishing rule relates to a particular or pre-configured Exchange On-Premise “path” such as -OWA, EWS an additional component that used in the ISA\TMG environment is the Authentication settings. Because ISA\TMG is a proxy server, many times the configuration of the authentication process implemented in the following way: external host authenticates (provide his credential) to the ISA\TMG, the ISA\TMG server approves or disapproves the credentials and if the complete successfully ISA\TMG will “forward in” the communication request of the external hosts. In the hybrid environment, this configuration will cause problem and errors. In simple words: when we publish Exchange On-Premise server using ISA\TMG server, we need to cancel or disable the option in which ISA\TMG server is authentication external host’s communication request. 6. Firewall Inbound And Outbound Access Policy | Office 365 And Exchange Online Public IP Range In many organizations, because of a regulation or other security requirements, there is an implementation of outbound and inbound policy that restricts access only to a dedicated or a predefined IP range. For example: when we say:” Exchange on-Premises server is creating a communication channel with Exchange Online,” what does is mean from the “IP range” point of view? Does Exchange Online infrastructure represented by a particular or a predefined public IP range? The answer to this question is: “Yes.” All the Office 365 environment such as – the Windows Azure Active Directory, Exchange Online, SharePoint Online and so on, based on a “publish” or well-known public IP range. The implementation of Outbound and inbound firewall rules that restrict the access only to a specific or a predefined IP range consider as “good practice” from the security point of view. But, at the same time, can complicate and interrupt the process of the “first-time configuration” that we use for building the “Hybrid communication channel” between the Exchange On-Premise and the Exchange Online server.Released – the Office Customization Tool
Today, the Office engineering team is announcing the general availability of the Office Customization Tool. With this new web-based tool you can easily customize the deployment of Office 365 ProPlus and other Click-to-Run managed Office products using a simple, intuitive, and web-based interface. The tool is an Azure-based cloud service which allows you to create XML configuration files that are used with the Office Deployment Tool. In the past, you needed to create the configuration files in Notepad or another text editor. The Office Customization Tool makes this part of the deployment process easier and less likely to introduce errors. This tool provides a simple experience which allows you to create a configuration file for use with the Office Deployment Tool, for scenarios where you need to customize the installation of Office 365 ProPlus. Common scenarios include: Initial installation of Office 365 ProPlus or Office 365 Business suites as well as Office 2019 suites, with the ability to include standalone products such as Visio and Project and various language packs. Adding additional products after the initial installation of the Office suite Adding additional language packs by configuring a ‘Language Only’ configuration after the installation of the Office suite or standalone products Standalone installation of Office 365 Access Runtime Installation of volume licensed products with automatic KMS and MAK activation Automatic removal of previous MSI based Office products To work with the service, go to https://config.office.com/ and choose the products, languages, and application settings you want to configure. For example, you can create a configuration file that downloads the 64-bit English version of Office 365 ProPlus, or you can create a file that installs the 64-bit English and German version of Office without Access and Publisher and with the EULA automatically accepted. When choosing a language, MatchOS is a popular option and allows Office to install support for the same languages that are installed for Windows on the targeted device. When you're done, you export the configuration file, which you can then use with the Office Deployment Tool or another software distribution solution to deploy Office in your organization. Choosing a product and a language are the minimum requirements to create a configuration file, but there are many more options to choose from to customize the deployment. Removal of existing MSI based Office products with the ability to ignore standalone products like Visio, Project, SharePoint Designer and InfoPath. These options ensure a smooth upgrade to the latest version of Office in a single deployment step. Choose to install and update directly from the Microsoft CDN or to host the Office package locally. Automatically accept the EULA and support for shared computer activation. Include Office application preferences to define the best experience for your users when they begin using the latest version of Office. You can also use the Office Customization Tool to make changes to existing configuration files, which is very useful when you need to modify the configuration of Office on devices that are already installed and configured or if you are creating a second or third configuration and you want to use your own baseline. Simply use the Import option and select the configuration file you wish to modify, make the desired changes, and use the Export option to generate a new configuration file. Are you using Configuration Manager to manage your deployments or configuration changes? If so you will be happy to know that as of 1806, Configuration Manager has integrated the Office Customization Tool with the Microsoft Office 365 Client Installation Wizard as part of their Application deployment workflow, giving administrators access to the same experience and the same set of features 1 described above. And if you haven’t yet upgraded to 1806, use the Office Customization Tool to generate the XML and incorporate that into your package. For more information, see the Overview of the Office Customization Tool. 1 – Some Click-to-Run deployment features are not compatible with Office deployments managed by Configuration Manager’s Application deployment workflow
