Using OpsMgr is relatively straightforward. The OpsMgr monitoring environment can be accessed through three sets of consoles: an Operations Console, a Web Console, and a command shell. The Operations Console provides full monitoring of agent systems and administration of the OpsMgr environment, whereas the Web Console provides access only to the monitoring functionality. The command shell provides command-line access to administer the OpsMgr environment.


Managing and Monitoring with OpsMgr
As mentioned in the preceding section, two methods are provided to configure and view OpsMgr settings. The first approach is through the Operations Console and the second is through the command shell.

Within the Administration section of the Operations Console, you can easily configure the security roles, notifications, and configuration settings. Within the Monitoring section of the Operations Console, you can easily monitor a quick up/down status, view active and closed alerts, and confirm overall environment health.

In addition, a web-based monitoring console can be run on any system that supports Microsoft Internet Explorer 6.0 or higher. This console can be used to view the health of systems, view and respond to alerts, view events, view performance graphs, run tasks, and manage maintenance mode of monitored objects. New to OpsMgr 2007 R2 is the capability to display the health explorer in the Web Console.


Reporting from OpsMgr
OpsMgr management packs commonly include a variety of preconfigured reports to show information about the operating system or the specific application to which they were designed to work. These reports are run in SQL Reporting Services. The reports provide an effective view of systems and services on the network over a custom period, such as weekly, monthly, or quarterly. They can also help you monitor your networks based on performance data, which can include critical pattern analysis, trend analysis, capacity planning, and security auditing. Reports also provide availability statistics for distributed applications, servers, and specific components within a server.

Reports are particularly useful for executives, managers, and application owners. These reports show the availability of any object within OpsMgr, including a server, a database, or even a service such as Lync Server 2010 that includes a multitude of servers and components. The availability report in Figure 13.6 shows that the LS1 Server was available until after 8:00 a.m. and then was down through 11:00 a.m.

The reports can be run on demand or at scheduled times and delivered through e-mail. OpsMgr can also generate HTML-based reports that can be published to a web server and viewed from any web browser. Vendors can also create additional reports as part of their management packs.


Using Performance Monitoring
Another key feature of OpsMgr is the capability to monitor and track server performance. OpsMgr can be configured to monitor key performance thresholds through rules that are set to collect predefined performance data, such as memory and CPU usage over time. Rules can be configured to trigger alerts and actions when specified performance thresholds have been met or exceeded, enabling network administrators to act on potential

performance issues. Performance data can be viewed from the OpsMgr Operations Console. In addition, performance monitors can establish baselines for the environment and then alert the administrator when the counter subsequently falls outside the defined baseline envelope.


Using Active Directory Integration
Active Directory integration provides a way to install management agents on systems without environmental-specific settings. When the agent starts, the correct environmental settings, such as the primary and failover management servers, are stored in Active Directory. The configuration of Active Directory integration provides advanced search and filter capabilities to fine-tune the dynamic assignment of systems.


Integrating OpsMgr Non-Windows Devices
Network management is not a new concept. Simple management of various network nodes has been handled for quite some time through the SNMP. Quite often, simple or even complex systems that use SNMP to provide for system monitoring are in place in an organization to provide for varying degrees of system management on a network. OpsMgr can be configured to integrate with non-Windows systems through monitoring of syslog information, log file data, and SNMP traps. OpsMgr can also monitor TCP port communication and website transaction sequencing for information-specific data management.

New to OpsMgr 2007 R2 is the capability to monitor non-Microsoft operating systems
such as Linux and UNIX, and the applications that run on them, such as Apache and
MySQL. OpsMgr monitors the file systems, network interfaces, daemons, configurations,
and performance metrics. Operations Manager 2007 R2 supports monitoring of the following
operating systems:

. HP-UX 11i v2 and v3 (PA-RISC and IA64)
. Sun Solaris 8 and 9 (SPARC) and Solaris 10 (SPARC and x86)
. Red Hat Enterprise Linux 4 (x86/x64) and 5 (x86/x64) Server
. Novell SUSE Linux Enterprise Server 9 (x86) and 10 SP1 (x86/x64)
. IBM AIX v5.3 and v6.1

Special connectors can be created to provide bidirectional information flows to other management products. OpsMgr can monitor SNMP traps from SNMP-supported devices as well as generate SNMP traps to be delivered to third-party network management infrastructures.


Exploring Third-Party Management Packs
Software and hardware developers can subsequently create their own management packs to extend OpsMgr’s management capabilities. These management packs extend OpsMgr’s management capabilities beyond Microsoft-specific applications. Each management pack is designed to contain a set of rules and product knowledge required to support its respective products. Currently, management packs have been developed for APC, Cisco, Citrix, Dell, F5, HP, IBM, Linux, Oracle, Solaris, UNIX, and VMware to name a few.

. A complete list of management packs can be found at the following Microsoft site:
http://pinpoint.microsoft.com/en-US/systemcenter/managementpackcatalog.

Source of Information : Pearson-Microsoft Lync Server 2010 Unleashed

• 0 comments »

OpsMgr is primarily composed of five basic components: the operations database, reporting database, Root Management Server, management agents, and Operations Console. These components make up a basic deployment scenario. There are also several optional components that provide functionality for advanced deployment scenarios.

OpsMgr was specifically designed to be scalable and can subsequently be configured to meet the needs of any size company. This flexibility stems from the fact that all OpsMgr components can either reside on one server or can be distributed across multiple servers.

Each of these various components provides specific OpsMgr functionality. OpsMgr design scenarios often involve the separation of parts of these components onto multiple servers. For example, the database components can be delegated to a dedicated server, and the management server can reside on a second server.

The following list describes the different OpsMgr components:

. Operations database—The operations database stores the monitoring rules and the active data collected from monitored systems. This database has a seven-day default retention period.

. Reporting database—The reporting database stores archived data for reporting purposes. This database has a 400-day default retention period.

. Root Management Server—This is the first management server in the management group. This server runs the software development kit (SDK) and Configuration service, and is responsible for handling console communication, calculating the health of the environment, and determining what rules should be applied to each agent.

. Management Server—Optionally, an additional management server can be added for redundancy and scalability. Agents communicate with the management server to deliver operational data and pull down new monitoring rules.

. Management agents—Agents are installed on each managed system to provide efficient monitoring of local components. Almost all communication is initiated from the agent with the exception of the actual agent installation and specific tasks that run from the Operations Console. Agentless monitoring is also available with a reduction of functionality and environmental scalability.

. Operations Console—The Operations Console is used to monitor systems, run tasks, configure environmental settings, set author rules, subscribe to alerts, and generate and subscribe to reports.

. Web Console—The Web Console is an optional component used to monitor systems, run tasks, and manage maintenance mode from a web browser.

. Audit Collection Services—This is an optional component used to collect security events from managed systems; this component is composed of a forwarder on the agent that sends all security events, a collector on the management server that receives events from managed systems, and a special database used to store the collected security data for auditing, reporting, and forensic analysis.

. Gateway Server—This optional component provides mutual authentication through certificates for nontrusted systems in remote domains or workgroups.

. Command shell—This optional component is built on PowerShell and provides full command-line management of the OpsMgr environment.

. Agentless Exception Monitoring—This component can be used to monitor Windows and application crash data throughout the environment and provides insight into the health of the productivity applications across workstations and servers.

. Connector Framework—This optional component provides a bidirectional web service for communicating, extending, and integrating the environment with thirdparty or custom systems.

Source of Information : Pearson-Microsoft Lync Server 2010 Unleashed

• 0 comments »

OpsMgr provides for several major pieces of functionality as follows:

. Management packs—Application-specific monitoring rules are provided within individual files called management packs. For example, Microsoft provides management packs for Windows server systems, Exchange Server, SQL Server, SharePoint, DNS, and DHCP, along with many other Microsoft technologies including Lync Server 2010. Management packs are loaded with the intelligence and information necessary to properly troubleshoot and identify problems. The rules are dynamically applied to agents based on a custom discovery process provided within the management pack. Only applicable rules are applied to each managed server.

. Event monitoring rules—Management pack rules can monitor for specific event log data. This is one of the key methods of responding to conditions within the environment.

. Performance monitoring rules—Management pack rules can monitor for specific performance counters. This data is used for alerting based on thresholds or archived for trending and capacity planning. There was a brief spike in latency at approximately 6:15 a.m., but the latency is normally under less than 0.05ms.

. State-based monitors—Management packs contain monitors, which allow for advanced state-based monitoring and aggregated health rollup of services. Monitors also provide self-tuning performance threshold monitoring based on a two- or three state configuration. The Lync Server Application Sharing service is stopped.

. Alerting—OpsMgr provides advanced alerting functionality by enabling email alerts, paging, short message service (SMS), instant messaging (IM), and functional alerting roles to be defined. Alerts are highly customizable, with the capability to define alert rules for all monitored components.

. Reporting—Monitoring rules can be configured to send monitored data to both the operations database for alerting and the reporting database for archiving.

. End-to-end service monitoring—OpsMgr provides service-oriented monitoring based on System Definition Model (SDM) technologies. This includes advanced object discovery and hierarchical monitoring of systems.

Source of Information : Pearson-Microsoft Lync Server 2010 Unleashed

• 0 comments »

System Center Operations Manager 2007 R2 released in spring 2009 and includes many new improvements on the previous version, Operations Manager 2007 Service Pack 1. Some of these improvements include

. Cross platform support—This supports non-Microsoft platforms such as UNIX and Linux. This enables administrators to have a single-pane view of their entire IT environment in OpsMgr.

. Integration with System Center Virtual Machine Manager 2008—This integrates with the VMM 2008 and enables synergies such as Performance Resource and Optimization (PRO) Tips, which provide virtual machine recommendations based on observed performance and the capability to implement the recommendation at the click of a button.

. Notifications—The notification system has been revamped and now includes an Outlook rule–style interface. Notifications can be generated for specific alerts, and notifications can be sent out as high-priority emails.

. Overrides view—Rather than hunt for overrides within all the management packs, OpsMgr R2 has an authoring view that shows all the overrides defined in the system.

. Improved management pack maintenance—OpsMgr 2007 R2 enables Microsoft management packs to be browsed, downloaded, and imported directly from the console. It even includes versioning, dependency checks, and the capability to search from management pack updates.

. Service level monitoring—Applications can be defined from various monitored objects and the service level of the application, and be monitored and reported on against defined target SLAs.

. Better scaling of URL monitoring—The URL monitor now scales to thousands of websites without undue performance impact.

. Improved database performance—The overall performance of the database and console has been dramatically improved.

These improvements bring the platform to a new level of performance and interoperability while retaining the look and feel of the original Operations Manager 2007 tool.

Source of Information : Pearson-Microsoft Lync Server 2010 Unleashed

• 0 comments »

Operations Manager 2007 R2 includes one of the best management packs for monitoring and maintaining Lync Server 2010. This management pack was developed by the product group and includes information about the product.

The Lync Server 2010 management pack monitors all the Lync Server 2010 server roles and has separate views for each of the roles to enable targeted monitoring in the console. The Lync Server 2010 management includes the following features:

. Automatic Lync topology discovery through the Central Discovery script—The Central Discovery script is a PowerShell script that runs on an automatically selected Central Discovery Watcher Node. This is the Front End pool where the Central Management Store is installed. The script automatically discovers and initiates monitoring of all Lync roles, components, and services.

. Automatic monitoring of pools—Front End and Edge pools are discovered automatically and monitored for a variety of availability, configuration, performance, and security conditions.

. Automatic alerting—The Lync Server management alerts on thousands of different conditions, enabling the administrator to immediately be aware of any potential problems in the infrastructure.

. Synthetic transactions to simulate user traffic—The management pack leverages the built-in Lync Server synthetic transaction PowerShell cmdlets.

The Microsoft Lync Server Management Pack monitors all aspects of the Microsoft Lync Server infrastructure. The management pack structures the monitoring into the services paradigm used by Lync Server. These services include
. Application Service
. Archiving Service
. Central Management Service
. Conferencing Service
. Core Service
. Edge Service
. Mediation Service
. Provisioning Service
. Registration Service
. User Service
. Web Service

On all these services, administrators can generate availability reports to ensure that the servers and systems are meeting the Service Level Agreements (SLAs) set by the organization. For each of the services, the management pack has views for
. Service alerts
. Service performance
. Service state

In addition, the OpsMgr platform monitors the Lync Server 2010 dependencies to ensure that the Lync Server 2010 infrastructure doesn’t fail due to a failure of the dependent systems such as the operating system, Active Directory, DNS, and IIS. The features of the management packs for the following major systems include

. Windows Operating System Management Pack—Monitors and alerts all the major elements of the Windows server that Lync Server 2010 runs on, including processor, memory, network, disk, and event logs. It gathers performance metrics and alerts on thresholds, and critical events.

. Active Directory Management Pack—Monitors and alerts on Active Directory key metrics such as replication latency, domain controller response times, and critical events. The management pack generates synthetic transactions to test the response time of the PDC emulator, LDAP, and other domain services.

. DNS Management Pack—Monitors and alerts on DNS servers for resolution failures and latency, and critical events.

. IIS Management Pack—Monitors and alerts on IIS services, application pools, performance, and critical events.

Source of Information : Pearson-Microsoft Lync Server 2010 Unleashed

• 0 comments »

System Center Operations Manager (OpsMgr) 2007 R2 provides the best-of-breed approach to monitoring and managing Lync Server 2010 within the environment. OpsMgr helps to identify specific environmental conditions before they evolve into problems through the use of monitoring and alerting components.

OpsMgr provides a timely view of important Lync Server 2010 conditions and intelligently links problems to knowledge provided within the monitoring rules. Critical events and known issues are identified and matched to technical reference articles in the Microsoft Knowledge Base for
troubleshooting and quick problem resolution. The management pack also provides for synthetic transactions to monitor services end-to-end.

The monitoring is accomplished using standard operating system components such as Windows Management Instrumentation (WMI), Windows event logs, and Windows performance counters, along with Lync Server 2010–specific API calls and PowerShell cmdlets. OpsMgr-specific components are also designed to perform synthetic transactions and track the health and availability of network services.

In addition, OpsMgr provides a reporting feature that enables administrators to track problems and trends occurring on the network. Reports can be generated automatically, providing network administrators, managers, and decision makers with a current and long-term historical view of environmental trends. These reports can be delivered through e-mail or stored on file shares to power web pages.

The following sections focus on defining OpsMgr as a monitoring system for Lync Server 2010. This chapter provides specific analysis of the way OpsMgr operates and presents OpsMgr design best practices, specific to deployment for Lync Server 2010 monitoring.

Source of Information : Pearson-Microsoft Lync Server 2010 Unleashed

• 0 comments »

After the server has been fully prepared for installation, the topology must be edited and published to reflect the new Edge Server pool. This involves editing the existing topology,
if it exists, and then republishing the topology so that all other servers in the environment
are aware of the new Edge Server pool.


Edit Topology
The next step in deploying an Edge Server is to edit the existing Lync Server topology. To edit the topology, perform the following steps:
1. Open the Lync Server Topology Builder.

2. When prompted to import an existing topology from Active Directory, click OK.

3. Expand the Site node where the Edge Server will deployed.

4. Right-click the Edge pools node, and select New Edge Pool.

5. Click Next to begin the wizard.

6. Enter the fully qualified name of the internal Edge Server pool in the Pool FQDN field.

7. Follow the appropriate following sections depending on whether a single Edge Server or pool of load-balanced Edge Servers will be deployed.


Deploying Standalone Edge Server
1. Select Single computer pool, and click OK.

2. If a single public IP address will be used for the Access Edge, Web Conferencing Edge, and A/V Edge services check the box Use a single FQDN and IP address. This requires using ports other than 443 for two of the services.

3. If federation is used, check the Enable federation box.

4. If the IP address used for the A/V Edge uses NAT, check the The external IP address of this Edge pool is translated by NAT box. Click Next when complete.

5. Under the SIP Access section, enter the external server FQDN and port. Typically, this is similar to sip.companyabc.com and port 443.

6. Under the Web Conferencing section, enter the external server FQDN and port. Typically, the name and port are similar to webconf.companyabc.com and port 443.

7. Under the Audio/Video section, enter the external server FQDN, IP address, and port. Typically, the name and port are similar to av.companyabc.com and port 443. Click Next when complete.

8. Enter an internal-facing IP address for the Edge Server pool and click Next.

9. Under the SIP Access section, enter the external IP address.

10. Under the Web Conferencing section, enter the external IP address.

11. Under the Audio/Video section, enter the external IP address and click Next.

12. If the A/V Edge IP address is translated by NAT enter the public IP address and click Next.

13. Select a next-hop pool to be used by the Edge Server pool and click Next. If a Director is deployed, that should be the next hop.

14. Place a checkmark next to any Front-End pools in the deployment that will use this Edge server pool for external web conferencing and A/V content. Click Finish to complete the wizard.


Deploying Load-Balanced Edge Server Pool
1. Select Multiple computer pool and click OK.

2. If a single public IP address will be used for the Access Edge, Web Conferencing Edge, and A/V Edge services on each server check the box Use a single FQDN and IP address. This requires using ports other than 443 for two of the services.

3. If federation is used, check the Enable federation box.

4. If the IP address used for the A/V Edge uses NAT, check the The external IP address

of this Edge pool is translated by NAT box. Click Next when complete.

5. Under the SIP Access section, enter the external server FQDN and port. Typically, this is similar to sip.companyabc.com and port 443.

6. Under the Web Conferencing section, enter the external server FQDN and port.
Typically, the name and port are similar to webconf.companyabc.com and port 443.

7. Under the Audio/Video section, enter the external server FQDN, IP address, and
port. Typically, the name and port are similar to av.companyabc.com and port 443.
Click Next when complete.

8. Click the Add button to define computers within the pool.

9. Enter the internal-facing IP address and internal FQDN of the server. Click Next.

10. Under the SIP Access section, enter the external IP address.

11. Under the Web Conferencing section, enter the external IP address.

12. Under the Audio/Video section, enter the external IP address and click Next.

13. If the A/V Edge IP address is translated by NAT enter the public IP address and click Next.

14. Repeat steps 8–13 for any additional Edge Server pool members and click Next when all nodes have been added.

15. Select a next-hop pool to be used by the Edge Server pool and click Next. If a Director is deployed, that should be the next hop.

16. Place a checkmark next to any Front-End pools in the deployment that will use this Edge server pool for external web conferencing and A/V content. Click Finish to complete the wizard.


Publish Topology
After the topology is modified to include the Edge Server pool, the configuration can be published. This step publishes the changes to the Central Management Store, and all existing Lync Server servers will update their local configuration stores to match.

1. Ensure that the Lync Server Topology Builder is open and contains the Edge Server pool recently added.

2. Click the top node of the management console, Lync Server.

3. Click the Action menu and select Publish Topology, or select Publish Topology from the Actions pane on the right side of the console.

4. Click Next to begin publishing the topology.

5. When the log indicates a successful update, click Finish to complete the wizard.

Source of Information : Wiley - Cloud Computing Principles and Paradigms 2011

• 0 comments »

The Edge Server hardware, operating system, and software Installation prerequisites.


Hardware Requirement
The Lync Server Edge Server processor requirements are as follows:
. Dual processor, quad-core 2.0 GHz or faster
. Four-way processor, dual-core 2.0 GHz or faster

The Lync Server Edge Server memory requirement is as follows:
. 12 GB RAM

The Lync Server Edge Server disk requirement is as follows:
. Local storage with at least 30 GB free space

The Lync Server Edge Server network requirement is as follows:
. Two 1 gigabit per second (Gbps) network adapters (recommended)


Operating System Requirements
The Lync Server Edge Server supports the following operating systems:
. Windows Server 2008, x64 Standard Edition with Service Pack 2
. Windows Server 2008, x64 Enterprise Edition with Service Pack 2
. Windows Server 2008, x64 Datacenter Edition with Service Pack 2
. Windows Server 2008 R2, Standard Edition
. Windows Server 2008 R2, Enterprise Edition
. Windows Server 2008 R2, Datacenter Edition

The Windows Server Core, Web, and High Performance Computing editions for any operating system version are not supported for deployment.


Software Requirements
The Lync Server Edge Server requires the following components to be installed:
. .NET Framework 3.5
. Visual C++ 2008 Redistributable
. PowerShell 2.0
. Windows Installer 4.0
. WinRM 2.0
. BITS 4.0

Server Roles and Features
Unlike the other roles in Lync Server, the Edge Server has no requirements for server roles or features. All the required components are included within the Edge Server installation.

Configure Networking
After the required components are installed, it is important to get the Edge Server networking configuration completed. An Edge Server must have at least two network adapters: one for external traffic and one for communicating with internal servers or clients.


Source of Information : Pearson-Microsoft Lync Server 2010 Unleashed 

• 0 comments »

The Lync Server Edge Server enables remote access to the internal Lync Server infrastructure. In addition to providing feature parity for external or remote users, the Edge Server can also enhance a deployment by federating with partner organizations or public IM providers. These federation features help organizations use rich communication methods securely with each other across the Internet.

The Edge Server role in Lync Server comprises three separate subroles just as in previous versions of the product: Access Edge Server, Web Conferencing Edge Server, and A/V Edge Server role. Each role provides slightly different functionality and depending on the organization’s requirements it might not be necessary to use all three services. With Lync Server 2010, all three roles are deployed together as opposed to individually like in previous product versions. Unlike many of the internal roles, the Edge Server does not require database or file shares because it does not store data other than the Local Configuration Store replica from the Central Management Store. Because the Edge Server is designed to be deployed in a perimeter or DMZ network, it runs a limited set of services to make it as secure as possible. Edge Servers are also typically not joined to the internal Active Directory domain, but can be if necessary. The reverse proxy server also provides some external services through the Front-End pool.


Access Edge
The Access Edge role serves as the core of the Edge Server and is responsible for all of the signaling functionality. Without the Access Edge role deployed, the Web Conferencing Edge and A/V Edge roles cannot function. The Access Edge also serves a few distinct purposes including remote access, federation, and Public IM Connectivity.

Remote Access
One function of the Access Edge Server is to provide remote access capabilities to a Lync Server infrastructure. After an internal deployment of pools is complete, an Access Edge Server can be provisioned to enable users to sign in and use their endpoints across the Internet. As long as the appropriate SRV records exist in DNS or the client is manually configured correctly, a user can travel in and out of the office without ever making a change to an endpoint. This enables users to have full access to their internal features regardless of location.

Federation
The Access Edge Server also provides the capability to federate with other organizations that have deployed Lync Server, meaning the two organizations can communicate with each other as if it were a single deployment. Users have different feature sets available when using federation, depending on the version of Lync Server a partner has deployed. The feature set is the lowest common denominator between the two organizations. For example, if a partner runs Live Communications Server 2005, only IM and presence will be available. However, if a partner organization is running Office Communications Server 2007 R2, A/V and Desktop Sharing features can be used through federation. The largest feature set is available if both organizations are running Lync Server. Access Edge Servers use certificates and mutual TLS (MTLS) to secure the SIP signaling used across the Internet with each other. This ensures that instant messaging and presence traffic is completely secure and never transmitted in plain text.

Public IM Connectivity
A special form of federation is the capability to use Lync Server to communicate with contacts on the public IM networks, referred to as Public IM Connectivity (PIC). The AOL, Yahoo!, and MSN networks are the native Public IM Connectivity providers to Lync Server. To communicate with these contacts, users simply need to add the address to a contact list. Lync Server users can see presence and exchange instant messages with their contacts when Public IM Connectivity is provisioned. The conversations are limited to peer-to-peer, though, and they cannot include three or more participants as users are accustomed to within the organization or with federated contacts. Audio and video support with the MSN or Windows Live networks is a new feature in Lync Server. The A/V conversations are performed using the same RTAudio and RTVideo codecs native to both platforms, but are also limited to two-party calls. As of this writing, only the Yahoo! network requires additional licensing, which is done on a per-user monthly subscription fee. As long as users have a Lync Server Standard CAL, the AOL and MSN Public IM Connectivity are provided at no extra cost.


Web Conferencing Edge
When joining a web conference, users first authenticate to the Access Edge Server before the client joins using the Web Conferencing Edge Server role. The Web Conferencing Edge Server enables remote users to participate in web conferences with internal users or other remote workers. Organizations may also elect to enable anonymous or unauthenticated users to join web conferences with their own users. This functionality is similar to what many hosted web conferencing services offer. However, it is provided by the organization’s own Lync Server infrastructure. Web conferencing uses Microsoft’s Proprietary Shared Object Model (PSOM) protocol to facilitate the meetings and data. Like the Access Edge traffic, all Web Conferencing Edge traffic is conducted over HTTPS port 443, so it is secure and resilient to proxy servers.


A/V Edge
The A/V Edge role is responsible for providing audio and video media exchanges among internal, external, and federated contacts. The A/V Edge role uses the Interactive Connectivity Establishment (ICE), Simple Traversal Utilities for NAT (STUN), and Traversal Using Relay NAT (TURN) methods to enable endpoints to communicate even if behind a NAT device. When possible, endpoints attempt to use a peer-to-peer connection for media streams, but when an endpoint is behind a NAT device such as a home router, the A/V Edge role can act as a relay point between the endpoints to facilitate communication. The A/V Edge service uses a combination of HTTPS port 443 and UDP port 3478 to negotiate and provide the media stream. To support media traffic between internal and external users, an additional service exists on the A/V Edge Server called the A/V Edge Authentication Service. This service is responsible for authenticating media requests from internal users to external contacts. When a user wants to initiate an external A/V conversation, she is provided with a temporary media token that she uses to authenticate to this service before media is allowed to flow.


Collocation
The Edge Server roles cannot be collocated with any other role in Lync Server. Although many of the other roles depend on access to Active Directory, Edge Servers are typically placed in a perimeter network and might not even be joined to the corporate domain for security reasons. In previous versions of Communications Server, it was possible to install only specific Edge roles. However, in Lync Server, the three roles are always installed together. This change cuts down on confusion of deployment models, which required knowing which Edge roles were safe to collocate together.


Reverse Proxy
In addition to the Edge Server roles that provide remote access, federation, web conferencing, and A/V conferencing, a reverse proxy is required to publish the web components services that don’t run through an Edge Server. The reverse proxy provides remote access to the web components running on Front End Servers or Edge Servers. This includes the following features:
. Address Book
. Distribution Group Expansion
. Device Updates
. Web Conferencing Content (Whiteboards and PowerPoint File Uploads)

Source of Information : Pearson-Microsoft Lync Server 2010 Unleashed

• 0 comments »