George Chetcuti Blog

Microsoft Lync is the latest edition (brand name) of MS Office Communications server products. As most of you may already know, Lync can be deployed locally within an organization (on-premise) or it can be purchased as a service from either Microsoft themselves or a third-party managed service provider (MSP). Briefly, to deploy Lync in your organization you need a license for each Lync Server 2010 instance and a Client Access License (CAL) for each user and device. Standalone and enterprise licensing models exist and this is similar to the other major products delivered by Microsoft. Conversely, if you go for a hosted solution then you would face a subscription licensing model which in my opinion is much simpler to handle!
The Server/CAL licensing model for on-premise implementations incorporates servers, clients and external connector components. Therefore, you need a license for each:

Server instance you will be running, whether Standard or Enterprise Servers

User accessing the servers, known as CALs and we find three types

Standard CAL – enables standard features for a user such as, IM and video & audio conferencing between internal computers
Enterprise CAL – enables enterprise features such as, extended conferencing features – External & Web
Plus CAL – enables plus features such as, VoIP features

To enable all features, a user must be licensed with all three CALs

External Connector, which is an external entity (travelling employee, business partner, etc.) connecting to your servers. There are three External Connectors which are Standard, Enterprise and Plus. External users' licenses can be purchased as CALs or ECs:

CAL – a license for each external user
EC – a license for each server (can have multiple instances) that will be accessed by an unlimited number of external users

Users' CALs (as explained in point 2

As we have seen in the previous post creating a customized Data Collector Set is pretty straight forward. Go here to read the post! In addition we have seen that the data sources defined were derived from a set template. In this post we are going to see how you can add your own data sources to a previously created set:
To customize an existing Data Collector Set follow these steps:

From Data Collector Sets\User Defined of Performance Monitor select your custom set, right click and select New, then Data Collector.

From the What type of data collector would you like to create? page, type a name for your new data source, select the type and click Next.

Performance Counter Data Collector – you can add as many performance counters as you like while you can assign a sample interval
Event Trace Data Collector – you can add a number of Event Trace Providers while you can modify their properties
Configuration Data Collector – you can add registry keys that you want to monitor.
Performance Counter Alert – you can add alerts for specific thresholds bound with performance counters

Click the remaining Ok and Finish buttons to complete the procedure.

Each Data Source can be later modified from the details pane (right hand side pane of performance monitor) by right-clicking it and selecting Properties. For instance the Configuration (Data Collector) source allows you to add configuration data other than registry keys set during the creation of the data source. You can add WMI management paths, file and state capture. Data sources that are no longer needed can be deleted from the list of sources in the user defined set.

 
 

Most Systems Administrators have used Performance Monitor to view real-time performance data on Windows servers and identify bottlenecks. Some may have also recorded sessions and later analyzed log files for performance issues. In fact, this is what I will be talking about in the couple of posts to come, mainly about Data Collector Sets. Data Collector sets gather system information, including configuration settings and performance data and store it in a data file. Before going to a brief explanation of how to create a Data Collector set, let's see some built-in features and basics:
AD Diagnostics set: this inbuilt Data Collector Set is only found in domain controllers and runs for 5 minutes. It logs data about the Kernel, Active Directory, AD registry configuration and performance counters.
LAN Diagnostics: this inbuilt Data Collector Set starts and stops manually and hence it runs until you stop it! It logs network performance counters, network configuration data and diagnostics tracing.
System Performance: this inbuilt Data Collector Set logs processor, disk memory, and network performance counters and kernel tracing. The System Performance counter stops automatically after one minute.
System Diagnostics: this inbuilt Data Collector Set logs detailed system information plus all the information included in the System Performance Data Collector Set. The System Diagnostics counter stops automatically after one minute.
Wireless Diagnostics: this inbuilt Data Collector Set is present only in computers with wireless capabilities and includes all the same information as the LAN Diagnostics set plus information relevant to troubleshooting wireless network connections. This set does not stop automatically and hence, you need to stop it.
To start a set, right click and then choose Start. If you are troubleshooting a problem, I suggest that you should try to replicate the problem if this is possible! You can view the results in the Reports node; however, right-clicki

As we have seen in Setting up an Event Collecting Computer you can use either Http or Https protocol to transfer data from the forwarding to the collecting computer. Although standard Http transport uses encryption for forwarded events, you can configure event forwarding to use the encrypted Https protocol. However, using Https requires the following additional tasks to be performed on the forwarding computers:

You need to install a certificate. You can do this automatically in Active Directory environments by using an enterprise CA.
You need to create a Windows Firewall exception for TCP port 443. If you opted to minimize bandwidth or latency in the collecting computer's Advanced setting – Event Delivery Optimization, then you must also add a Https firewall exception rule and install a certificate on the collecting computer.
At an elevated command prompt type: winrm quickconfig – transport:https

Finally, from the Advanced Subscription Settings on the Collecting computer you need to click the Protocol: drop-down arrow and select HTTPS as show below:

Events are collected or sent (when subscription configuration is set to normal) every 15 minutes which is quite adequate for normal operations; however, there might be critical periods for some resources that we need to reduce this delay and get critical events faster. As already noted in Setting up an Event Collecting Computer, with the help of the wecutil command-line tool we can modify this parameter. The wecutil syntax is as follows:
wecutil ss "subscription_name" /cm:custom
wecutil ss "subscription_name" /hi:<milliseconds_delay>
where the only parameters you need to specify are the subscription name and the delay in milliseconds, for example:
wecutil ss "Test Subscription" /cm:custom
wecutil ss "Test Subscription" /hi:30000
would set our current subscription called "Test Subscription" to 5 minutes intervals. The interval parameter is called HeartbeatInterval as shown below:

To display the current configuration, at an elevated command prompt type:
wecutil gs "Test Subscription"
For a full list of the wecutil command options type wecutil /? at the command prompt.
 

Having set up all remote hosts that you will be retrieving Events from, it is time to configure the Collecting workstation. The collecting computer would normally be an admin computer running Windows Vista, Windows 7 or Windows Server 2008. Assuming our collecting computer is named env1client01 then, from an elevated command prompt type:
wecutil qc
This command will set Windows Event Collector service from Manual to Delay-Start.
Next, we need to create an Event Subscription as follows:

Open Event Viewer on evn1client01 (Collecting computer), right click Subscriptions and select Create Subscription.

A Subscription Properties window should appear as shown below, type a name and a description:

There are two types of Subscriptions, you can use the default type:

Collector initiated – where the collecting computer contacts the source computers to retrieve events. I suggest that you test the added computers by clicking the Test button from the Select Computers… option.
Source computer initiated – where all forwarding computers send events to the Collecting computer. Non-domain computers need to have a certificate installed to be able to connect successfully, in fact, domain related issues will prevent proper flow of events!

Next, click Select Events… button and define the error criteria such as, levels, log, source, etc. that will be used to match and collect events.

The Advanced… button loads optional settings which are:

User Account – whether you want to use specific user or machine account. The account must be a member of the forwarding computer's Event Log Readers group.
Event Delivery Optimization – where you can save the bandwidth consumed (when monitoring over a WAN) or force a push delivery mode to get events faster (when monitoring critical services) or use the default normal behavior which ensures a reliabl

You may be contemplating of building a quick test environment using a free virtualization solution on a high spec PC. This is quite a cheap but effective solution, even in large organizations where an IT department or an individual entity can build a test platform isolated from the production environment. Say, a core i7 CPU computer with 6/8GB of Ram and 4TB of storage space would make a perfect test lab! Check Deb's superb article about setting up a base test setup here. Whether you will be using Microsoft's Hyper-V, Citrix's Xen or VMware's ESX make sure that you reduce the threats that a test lab may introduce to your network resources.
In the event you will be using Hyper-V as your test environment then I recommend that the virtualized host machine (PC) is NOT joined to the organization's domain but if your admin workstation (Hyper-V Manager) is part of the domain then go for a setup that resembles Client-domain and Server-workgroup as denoted in the Hyper-V Remote Management Configuration Utility web page.
To assist you with the installation of Hyper-V from Windows 7 follow this great video by David Davis on VirtualizationAdmin.com – It is very important that with this scenario you might need to set the IP address of your Hyper-V host PC or server in your Windows 7 hosts file. Since, the virtualized host PC or server is not in the domain it may not register itself with the internal DNS! So watch out for DNS issues if you fail to connect remotely and start getting RPC error messages.

Windows Event forwarding requires the setup of forwarding computers and a collecting computer as we have seen in Managing Windows Events. In this post we start by setting up a typical forwarding computer and proceed to the collecting computer setup in another post. Let's assume that we are collecting events from a Windows 2008 server named Win2k8Web, hence our first forwarding computer is Win2k8Web.
To set up the forwarding computer follow these steps:

We need to configure the Windows Remote Management service first. Log on to Win2k8Web, open an elevated command prompt and type: winrm quickconfig

Type Y to the requested changes. These depend on the current configuration but WinRM would need:

To start the WinRM service and set it to auto-start.
To grant administrative rights when the computer is not part of a domain
To allow remote access
To create a WinRM listener on HTTP://* to accept WS-Man requests by creating a firewall exception – Note, this firewall exception does not apply to Public networks.

Next, we need to add the computer account of the collecting computer to the local Event Log Readers group. Assuming that the collecting computer (my admin workstation in the domain env1.testlab) is named env1client01, then at an elevated command prompt on Win2k8Web type: net localgroup "Event Log Readers" [email protected] /add

In the above procedure we have configured the Win2k8Web host as a forwarding computer where it allows the collecting computer env1client001 to have remote access and collect events. In the post to follow, we will configure the collecting computer.

The wealth of info stored in Windows event logs is astonishing. But most often we miss what we are looking for as the amount of information stored may be overwhelming at times. There are various third-party tools out there that manage and organize event logs in a useful manner; however, I would like to share with you some Event Forwarding Concepts that allow administrators collect and group specific events to one location. With Event Forwarding you can send specific events from individual computers to a target computer or your admin workstation. Then you would be able to view the most important events grouped into one event log/viewer from your workstation rather than connecting remotely to each and every target machine. One of the core advantages of Windows Event Forwarding is that it uses HTTP (Hypertext Transfer Protocol) and HTTPS (Hypertext Transfer Protocol Secure) protocols to transfer data and as such, the traffic can flow easily through firewalls within an organization, assuming that the organization IT Policies allow web browsing! All traffic generated by the forwarding mechanism is encrypted even if you use HTTP. The implementation process requires a two-part exercise. That is, you need to configure both target (forwarding) and receiving (collecting) computers. Both computers need to have the Windows Remote Management and the Windows Event Collector services up and running. Note, that only Windows Vista, Windows Server 2008 and Windows Server 2003 R2 can have the role of a collecting computer. In addition, you may need to add firewall rules that allow incoming/outgoing traffic to/from services participating in the process.