Determining A/V Firewall and Port Requirements for Lync Online

Posted on Updated on

lync_2010_med

Use the following Firewall and Port table to determine firewall requirements and which ports to open. Then, review the network address translation (NAT) terminology because NAT can be implemented in many different ways. For a detailed example of firewall port settings, see the reference architectures in Topologies for External User Access.

A/V Firewall and Port Requirements

Federation Feature TCP/443 UDP/3478 RTP/UDP 50,000-59,999 RTP/TCP 50,000-59,999
Lync Server 2010 A/V Open inbound Open inboundOpen outbound Do not open in either direction Open outbound
Lync Server 2010 Application sharing/desktop   sharing Open inbound Open inboundOpen outbound Do not open in either direction Open outbound
Lync Server 2010 File transfer Open inbound Open inboundOpen outbound Do not open in either direction Open outbound
Office Communications Server 2007 R2 A/V Open inbound Open inboundOpen outbound Do not open in either direction Open outbound
Office Communications Server 2007   R2 Desktop sharing Open inbound Open inboundOpen outbound Do not open in either direction Open outbound
Office Communications Server 2007   R2 File transfer N/A N/A N/A N/A
Office Communications Server 2007 A/V Open inbound Open inbound Open inboundOpen outbound Open inboundOpen outbound
Office Communications Server 2007 Desktop sharing N/A N/A N/A N/A
Office Communications Server 2007 File transfer N/A N/A N/A N/A

 

Note: (inbound) refers to RTP/TCP and RTP/UDP traffic from the Internet to the A/V Edge external interface.
(outbound) refers to RTP/TCP and RTP/UDP traffic from the A/V Edge external interface to the Internet.

External A/V Firewall Port Requirements for External User Access

The firewall port requirements for external (and internal) SIP and conferencing (PowerPoint presentations, whiteboarding and polling) interfaces are consistent, regardless of the version your federation partner is running.

The same is not true for the Audio/Video Edge external interface. In most cases, the A/V Edge service requires that external firewall rules allow RTP/TCP and RTP/UDP traffic in the 50,000 through 59,999 port range to flow in one or both directions. For example, opening this port range is required to support certain federation scenarios and the preceding table provides the details for each scenario. The table assumes that Lync Server 2010 is the primary federation partner and it is being configured to communicate with one of the four federation partner types listed.

Note: Regarding the 50,000-59,999 port range, the best practice for Lync Server 2010 is to open it outbound, to “Any” for RDP/TCP for the A/V Edge external interface if corporate policy allows.

NAT Requirements for External User Access

NAT is typically a routing function, but newer devices such as firewalls, and even hardware load balancers can be configured for NAT. Rather than focusing on which device is performing NAT, this topic describes the required NAT behavior instead.

Microsoft Lync Server 2010 communications software does not support NAT for traffic to or from the Edge internal interface, but for the Edge external interface, the following NAT behavior is required. This documentation uses the acronyms ChangeDST and ChangeSRC in tables and drawings to define the following required behavior:

  • ChangeDST   The process of changing the destination IP address on packets destined for the network that is using NAT. This is also known as transparency, port forwarding, destination NAT mode, or half-NAT mode.
  • ChangeSRC   the process of changing the source IP address on packets leaving the network that is using NAT. This is also known as proxy, secure NAT, stateful NAT, source NAT or full-NAT mode.

Regardless of the naming convention used, the NAT behavior required for the external interface of the Edge Server is as follows:

  • For traffic from the Internet to the Edge external interface:
    • Change the destination IP address of the incoming packet from the Edge external interface public IP address to the translated IP address of the Edge external interface.
    • Leave the source IP address intact so that there is a return route for the traffic.
  • For traffic from the Edge external interface to the Internet:
    • Change the source IP address of the packet leaving the Edge external interface, from the translated IP address to the public IP address of the Edge external interface so that the internal Edge IP address is not exposed and because it is a non-routable IP address.
    • Leave the destination IP address intact on the outgoing packets.

The following figure shows the distinction between changing the destination IP address (ChangeDST) for inbound traffic and changing the source IP Address (ChangeSRC) for outbound traffic using the A/V edge as an example.

Changing the destination IP address (ChangeDST) for inbound traffic and changing the source IP Address (ChangeSRC)

Im_routing

The key points are:

  • For traffic incoming to the A/V Edge, the source IP address does not change but the destination IP address changes from 131.107.155.30 to the translated IP address of 10.45.16.10.

For traffic outbound from the A/V Edge back to the workstation, the source IP address changes from that of the server’s public IP address to that of the A/V Edge’s public IP address. And the destination IP remains the workstation’s public IP address. After the packet leaves the first NAT device outbound, the rule on the NAT device changes the source IP address from the A/V Edge’s external interface IP address (10.45.16.10) to its public IP address (131.107.155.30).

How to Identify a Directory Synchronized User via O365 MSODS User Attribute

Posted on Updated on

PowerShell_Logo_sm

In Office 365 Directory Synchronization is still the BEST option for managing both your online and on-premises users, contacts and groups. Office 365 determines whether an object is being managed by an on-premises Active Directory’s Directory Synchronization tool by the O365 MSODS sourceAnchor attribute. This attribute is calculated from the on-premises user’s Domain GUID, performing a double Base64 encoding procedure and synchronizing that into the cloud.

This sourceAnchor is NOT exposed via PowerShell or any other UI or tool, so it is very difficult to determine if an online object is being managed by DirSync other than whether an online object’s fields, such as name, telephone number, etc are grayed out and ready only.

In order to determine whether an online object is being managed via DirSync, a PowerShell connection into the Microsoft Online Directory Service (MSODS) environment and look specifically for ImmutableID, which is an exposable attribute that reflects the online user’s sourceAnchor.

Steps to Review Online User ImmutableID

  1. Download and install the Microsoft Online Services PowerShell for Windows
    1. http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652560.aspx#BKMK_DownloadTheMOSIdentityFederationTool
      1. x86: http://go.microsoft.com/fwlink/?linkid=236345
      2. x64: http://go.microsoft.com/fwlink/?linkid=236293

     

  2. Launch PowerShell and connect to Office 365 MSODS and query for an ImmutableID for user@contoso.com
    $Cred=get-credential – [Microsoft Online Global Administrator creds] 
    Connect-MSOLService –Credential $cred 
    Get-MsolUser –UserPrincipalName user@contoso.com | FL Immut*

BPOS-S Transition Phased Process Explained

Posted on Updated on

Understand the BPOS to Office 365 Transition process is instrumental in supporting your end users as your BPOS tenant moves into Microsoft’s new Online Services, namely Office 365!  Below is an explanation on how the BPOS to Office 365 Transition flow happens over the Transition Weekend, to help you as an Online Administrator and/or end-user what to expect:

Phase-Name

Phase Name is the Phase the tenant is in, such as:

  • Pre-Approval: Holding for a Batch
  • PrimaryPrep: Initial phase where email/communication goes out (T-60 – T-30)
  • SecondaryPrep: Secondary phase where reminder email/communication goes out (T-30)
  • Approval: Final communication phase where reminder email/comm goes out (T-14)
  • Pre-Stage: Pre-Copy of all content to O365 (T-7)
  • Lock: Locking of the tenant admin (T-1)
  • DataUpgrade: The actual transition (T)
  • Finalize: Post transition cleanup and enable of tenant admin (~T+48 hours)

TenantStatus

Tenant Status Is the current status IN the current phase.

  • Complete: All work done, or no outstanding work in that phase.
  • Pending: Waiting for work to be picked up in the phase
  • InProgress: Work in the phase is going on
  • Error: One or more workitems had an error and is waiting human interaction
  • Warning: One of more workitems had hit a retry condition

PreApproval

Pre-Approval Complete, means that the tenant is holding to be placed on a batch, and no work is waiting to be done.  This tenant most likely is constrained from being placed onto a batch and is sitting in this phase.

Determine When Users Have Changed Their BPOS-S Password – All Users Must Change BEFORE BPOS Transition

Posted on Updated on

Image

As your BPOS company comes closer to being Transitioned into Office 365, each online company administrator must verify that each of their users have changed their passwords, in order to synchronize these passwords into Office 365. Doing these steps will ensure that once the company is transitioned, the users will use the same password in the new Office 365 environment.

To help Online Administrators, they should first download the latest Microsoft Mailbox Transporter Tool, which includes updated PowerShell scripts, which can be used to query (Get-MSOnlineUser) BPOS-S for user password changes, allowing you to determine which users have not changed their password. You can then reach out to them and ask for them to change OR you can use the Set-MSOnlineUser command to set a password for them, which will then be synchronized into Office 365!

Resources:

Find All Users Who Have Not Changed Passwords Since 12/1/2011 and Change Password to “P@ssw0rd1” and Force to Change at Next Logon

  • $Cred = Get-Credentials [enter your BPOS Administrator account credentials]
  • Get-MSOnlineUser -Credential $Cred -enabled | where {$_.PasswordLastSetDate –lt “12/1/2011”} | Set-MSOnlineUserPassword -Password “P@ssw0rd1” –Credential $Cred –ChangePasswordOnNextLogon $true

The above will query the BPOS Microsoft Online Directory Services (MSODS) for users who have NOT changed their password since December 1st, 2011. Anyone in this PowerShell (in-memory) list will then be piped to the Set-MSOnlineUserPassword and change these users passwords to “P@ssw0rd1” and instruct MSODS to force the user to change their password during their next login. Of course you will need to tell these users that their password has changed to P@ssw0rd1, as they will need this to change their password!

Note – If you want to run the following, it will give you the list, and then you can run the full command to set the password for these users. This way you will have a list of people that you need to contact with their new password:

GET LIST OF USERS WHO HAVE NOT CHANGED THEIR PASSWORDS SINCE DECEMBER 1, 2011

  • $Cred = Get-Credentials [enter your BPOS Administrator account credentials]
  • Get-MSOnlineUser -Credential $Cred -enabled | where {$_.PasswordLastSetDate –lt “12/1/2011”} | FL Identity

Welcome to Microsoft Online Services Blog

Posted on Updated on

Welcome to my public Blog site, which is dedicated to discussing in as much detail as possible, all aspects of Microsoft Online Services.  I will do my best to post at least 6-12 articles per week and hope that others in the Microsoft Online Services Community will join me in contributing their experiences in Online Services to this Blog location.  I will specifically be blogging in the following areas:

Business Productivity Online Services (BPOS)

  • Usability
  • Configuration
  • Administration
  • Transitions into Office 365

Office 365 Online Services

  • Usability
  • Configuration
  • Administration
  • Coexistence and Federation between on-premises and Online Services.