2017 ~ LazyExchangeAdmin

Being the Lync / SfB Administrator of your company, you may at times need to look up the Federation SIP Address of another domain. It may happen that a federated partner domain decided to change their SIP Address or perhaps they've migrated their Lync On-Premise infrastructure to O365/Skype Online, and you need to update your own Lync organization with that new SIP Address.
Federation utilizes the SRV DNS record with a specific format, and for this, you can use the good old nslookup utility.

In this example, we are looking for the Federation SIP Address for microsoft.com. The result is sipfed,microsoft.com

C:\>nslookup
> set q=srv
> _sipfederationtls._tcp.microsoft.com
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
_sipfederationtls._tcp.microsoft.com SRV service location:
priority = 0
weight = 0
port = 5061
svr hostname = sipfed.microsoft.com
>

Looking at the example, the federation sip address always starts with _sipfederationtls._tcp. and followed by the actual domain.

eg.
_sipfederationtls._tcp.amazon.com
_sipfederationtls._tcp.contoso.com

References:
https://technet.microsoft.com/en-us/library/jj618369(v=ocs.15).aspx
http://windowsitpro.com/skype-business/understanding-main-types-federation-skype-and-lync-environments
https://www.petri.com/setup-lync-federation

If you're not interested in reading the entire post, you can skip to the solution.

I know there have been many articles written and available for this topic. The reason I decided to still write this is to provide more explanation to possible questions that I found myself asking too when I first encountered this situation.

To understand what Windows Fabric is, what is does and how it works you may refer to this link -
"Understanding how Windows Fabric Works (with regards to Lync)"

There are two (2) User Defined Collector sets by default when a Lync Front-End server is deployed.

FabricLeaseLayerTraces
FabricTraces

You can find these in Performance Monitor

And the default location of the files generated by these data collectors is in C:\ProgramData\Windows Fabric\Fabric\log\Traces folder of each Front-End server.

The screenshot above is from one of the FE Servers in my lab setup. As you can see there are multiple files with approximately 128MB size each. What happens is that once the log file reached a new log file is generated with an incremental version.

eg.

fabric_traces_130374156934210426_007625.etl
fabric_traces_130374156934210426_007626.etl

And there is no limit as to how many of these files are created and can ultimately use up all available free space.

So the questions:

Why the 128MB Maximum file size?

It can be any size really, it's just that 128MB is the default when the data collector was created. You can simply check this using the logman utility.

What triggers the data collector to start?

A Task is scheduled to run at system startup which calls the "StartTracing.cmd" batch file.

Where can I find StartTracing.cmd and how is Task Scheduler able to call it when there is no relative path indicated in the Task?

A relative path (eg. C:\Windows\etc\whatever.exe) is not necessary because the file StartTracing.cmd is located in a path that is already defined in the Environment Variables.

Think of notepad for example which you can run by just typing notepad.exe without having to specify the path - that is the same concept.

How do I stop Windows Fabric from generating multiple log trace files?

The short answer is to turn on Circular Logging.

How? According to this article - http://flinchbot.com/2014/02/28/the-hidden-logs-that-could-crash-your-lync-servers/ - you can turn on circular logging by running this command (from an elevated command prompt)

Logman update trace FabricLeaseLayerTraces -f bincirc --cnf

I did use that article as a guide to enable the Circular Logging for both collectors, but somehow logman still kept on generating new files. I'm not saying that it is wrong, only that some parameters were not included to achieve my intended outcome.

So why didn't it work? That is because despite circular logging being turned on, the versioning is still enabled and the overwrite switch was not specified. In order to really turn on Circular Logging and keep the number of files to 1, this is what I did:

Solution

Run these commands in an elevated command prompt:

Logman update trace FabricLeaseLayerTraces -f bincirc --v --cnf -ow
Logman update trace FabricTraces -f bincirc --v --cnf -ow

What do the switches mean?

-f bincrc = turn on circular logging
--v = turn off file versioning
--cnf = turn off creation of new files
-ow = turn on overwrite of existing log file

Temporarily stop the logging

logman stop fabricleaselayertraces
logman stop fabrictraces

(Optional) Delete the existing log files

del "C:\ProgramData\Windows Fabric\Fabric\log\Traces\*.*"

Start logging

logman start fabricleaselayertraces
logman start fabrictraces

The Result?

Notice that the versioning has been removed.

The same log files will be overwritten every time.

Also, you may want to consider increasing the maximum file size to a much higher value (like 2GB or higher) since there will only one log file for each data collector.