I ran into an issue recently where we noticed that an Exchange volume was increasing with size at an alarming rate. Digging into the matter more discovered that the log folder had, get ready for this over 700K logs. So yes do the math, with each log being 1mb in size that came to over 700GB worth of logs. So the next thing was to find out what was causing this or who was causing this.
This is where Exmon came in handy for now we could track down which mailbox (if any) was causing this. The next thing that is going to be important for you to figure out is what columns are important. Well the CPU usage which is the % of resources out of 100 that a particular user is using of the Exchange store.
The second thing that was important was the Log bytes column which tells you how many logs that particular person is generating on the Exchange server. If you find a particular user that has a out of the ordinary high count in the log bytes column you should look into it for that could be your answer.
So now that you have identified the user now what? There are two options you can try, 1) You can try to move that user to another database and see if the issue follows the user. 2) Have the user recreate his profile. Now why would you have the user recreate his profile? Because a message is corrupt in his mailbox which is causing the excessive logs files in the log folder of your storage location. Another thing you can do to confirm that you have found the problem user is have the user close out of outlook and look at Exmon again. If you notice that the selected user drops off the CPU usage column and their Log bytes goes to O, then you might have identified your user. What we did was look in the log folder and see if your logs stop increasing at the alarming rate once the user shuts down outlook.
Hopefully this helps you out.
There will be times when you need to find out which users are on which servers. I have run into this many times and it was upsetting that I couldn’t find the information like I could in OCS 2007 R2. So there are some cmdlets to a point that will allow you to find a single person, but what about an entire server? This is where it gets tricky and challenging.
Here is a sample of the output of the tool where I was able to run the tool and get some data back about user’s and what their client version is. In addition I was able to see if this person was connecting remotely, their IP address, and the server they reside on.
Now what about finding the different clients connected to the Lync servers? The tool allows for that type reporting as well, see below.
So I will save you the suspense and tell you where to find this amazing tool….http://www.stumper66.com/software/lync.html
Hopefully this helps many of the Admins out there.
The following link talks about the requirements about the Lync Geo Cluster Scenario and whats supported. Here is a small glimpse of the requirements:
All servers that are part of geographically dispersed clusters must be part of the same stretched VLAN, using the same Layer-2 broadcast domain. All other internal servers running Lync Server server roles can be on a subnet within that server’s local data center. Edge Servers must be in the perimeter network, and should be on a different subnet than the internal servers. Also, the perimeter network need not be stretched between sites.
Synchronous data replication must be enabled between the primary and secondary sites, and the vendor solution that you employ must be supported by Microsoft.
Round-trip latency between the two sites must not be greater than 20 ms.
Available bandwidth between the sites must be at least 1 Gbps.
A geographically dispersed cluster solution based on Windows Server 2008 R2 Failover Clustering must be in place. That solution must be certified and supported by Microsoft, and it must pass cluster validation as described in the Windows Server 2008 R2 documentation. For details, see the “What is cluster validation?” section of “Failover Cluster Step-by-Step Guide: Validating Hardware for a Failover Cluster” at http://go.microsoft.com/fwlink/?linkid=142436.
All geographically dispersed cluster servers must be running the 64-bit edition of Windows Server 2008 R2.
All your servers that are running Lync Server must run the Lync Server 2010 version.
All database servers must be running the 64-bit edition of one of the following: Microsoft SQL Server 2008 with Service Pack 1 (SP1) (required) or latest service pack (recommended)
Microsoft SQL Server 2008 R2
Lync Server 2010 has a delegation feature that enables users the ability to enable delegation to other Lync users to recieve and make calls on another person behalf. Now you can go and make someone a delegate by going to
Call Forward settings
Edit my delegate members
Clicking add, and then adding the people you want (you can not add federated users as delegates)
Now the interesting piece is that Lync delegation can leverage Exchange delegates. So this means Lync 2010 can leverage your existing delegation settings from either Inbox and or Calander settings.
Now the issue I ran into before was a user asked me a few questions:
Question: How did the delegates for Lync just appear there?
Answer: If a end user has users delegated in Outlook in either their Inbox or Calender then those delegates are going to appear in Lync automatically.
Question: Does that mean that the people in my Lync delegate will recieve my phone calls on my behalf?
Answer: Not necessarily, you will have to go into Lync (see above) and select a user with a check box?
Question: So why is it that when I go to try to remove some people from my Lync delegation area that just keep coming back?
Answer: Well, in Outlook you can give people different levels of access. For those users that you give “Editor” permissions in your calender, you are giving those users the ability to schedule meetings on your behalf. So just because you remove them from Lync as a delegate they are going to reappear.
Question: How do I get those users in my Lync delegation to not come back?
Answer: By editing those users permissions in your Oulook calender from Editor to Reviewer you should be able to remove them from Lync (see above) and those users will not reappear anymore.
Hopefully this is helpful information going forward.
Here is a listing of the Lync 2010 webcast that I delivered:
Microsoft Lync 2010 Voice Deployment -
Deep Dive: Lync Server 2010 Conferencing -
Microsoft Lync 2010 High Availability and Resiliency -
Deep Dive: Lync Server 2010 Edge Servers -
Lync Server 2010 Migration and Coexistence -
Lync Server 2010 Architecture Topologies -
Lync Server 2010 Role Based Access Control -
Lync Server 2010 Implementing Call Admission Control -
Here is another webcast session that I delivered on Lync 2010 High Availability and Resiliency.
Meeting Questions and Answers:
Subject: TechNet Webcast: Microsoft Lync 2010 High Availability and Resiliency
Question: What is a Registrar Pool? it is not one of the Lync server roles, so what exactly is a Registrar?
Answer: When the Lync client signs in, it will register with the Front End Server or Director. The Director is running the registrar service just like the Front End Server.
Question: any known issues around draining/ I tried and it disconnected my current sessions
Answer: I have not seen issues where turning on draining caused current sessions to be disconnected. That is contrary to what the feature is supposed to do.
Question: So the HLB will round robin through the 3 front ends and the Front Ends will then talk to each to figure out what the primary registrar is for a client..correct? If so..what happens if the the primary registrar goes down..will a new registrar be chosen for the client?
Answer: In a resiliency configuration, the user is assigned a backup registrar pool when they register with their primary registrar.
Question: Does Lync support SIP DNS load balancing with SRV records, instead of multiple A records?
Answer: No, you need to have multiple A records.
Question: in dns lb why aren’t cnames used for ocspool1 hosts?
Answer: You are technically creating an A record for each server in the pool that happens to have the same name as the pool. The CNAME record points to an A record so you have to have the A record first.
Question: What are the latency requirements between the DC to DC failover options and SBA to DC failover scenario?
Answer: There are not any specific “latency” requirements for failover to another DC or from SBA to DC. As a right provisioning standard, provision your network to ensure a maximum end-to-end delay (latency) of 150 milliseconds (ms) under peak load.
Question: the a records are created by building the front end servers so a records for these IPs are already created so then when you configure your pool and dns lb you can create cnames for the pool to the server names…. this way if the server IP changes the pool still stays alive. right?
Answer: The Pool needs to have an A record to function.
Question: When we need to use a Director?
Answer: The Director is not required, but recommended depending on your configuration.
Question: So Full services are available for remote user who’s home server (SBA/SBS) is down,,what about if user is homed to another pool? Do they have limited functions?
Answer: Provided the resiliency is configured correctly for all pools, then they would have full functionality.