Getting a very odd error when trying to turn on siptcpport5060 with set-csregistar


  • When i run "set-csregistrar registrar:fqdn -sipservertcpport 5060" i get this error :


    PS C:\Users\trichert> set-csregistrar -Identity Registrar:corplync01.corp.usmmll -SipServerTcpPort 5060
    Set-CsRegistrar : GruuType must have a length of at least 1.
    At line:1 char:16
    + set-csregistrar <<<<  -Identity -SipSer
    verTcpPort 5060
        + CategoryInfo          : InvalidArgument: (Registrar:corplync01.corp.usmm [Set-CsRegistrar], PropertyArgumentOutOfRangeException
        + FullyQualifiedErrorId : InvalidUpdate,Microsoft.Rtc.Management.Xds.SetRe


    I've rebooted, restarted services, googled have not found a single example of anyone having this issue.  Can anyone help please?

    Thursday, August 04, 2011 7:22 PM

All replies

  • Hi Todd,

    From the output it seems the command format is incorrect. Try

    set-csregistrar -Identity "" -SipServerTcpPort 5060

    One of the example on technet : Set-CsRegistrar -Identity "" -SipPort 5072


    Navin Microsoft Unified Communications
    Saturday, August 06, 2011 10:23 AM
  • For me is doing the same thing:

    PS C:\Users\administrator.FIRSTMEDICALPR> set-csregistrar -Identity "Registrar:m" -SipServerTcpPort 5060
    Set-CsRegistrar : GruuType must have a length of at least 1.
    At line:1 char:16
    + set-csregistrar <<<<  -Identity "" -SipServer
    TcpPort 5060
        + CategoryInfo          : InvalidArgument: (Registrar:mls.firstmedicalpr.c
       om:String) [Set-CsRegistrar], PropertyArgumentOutOfRangeException
        + FullyQualifiedErrorId : InvalidUpdate,Microsoft.Rtc.Management.Xds.SetRe

    Sunday, August 07, 2011 5:54 PM
  • It is not a syntax problem.  Anyone ever find a fix for this? 
    Monday, August 08, 2011 11:35 AM
  • Are you using a pool's name, or an actual servername?

    You should be targeting the poolname.

    Both set-csregistrar registrar:fqdn -sipservertcpport 5060" and "Set-CsRegistrar -Identity "registrar:fqdn" -sipservertcpport 5072" should work.

    Lasse Wedø,
    Blog:Tech@work, Twitter: @lawedo

    Please take a second to hit the green arrow on the left if the post was helpful, or mark it as an answer if it resolved your issue.
    Monday, August 08, 2011 12:16 PM
  • hi,

    i noticed this as well on my test platform AFTER i installed the latest LYNC CU (KB 2493736). Had to rebuild the server to get rid of it.

    Tuesday, August 09, 2011 11:53 AM
  • How did you rebuild the server without loosing your config?  I take it you can't just uninstall the update ?  (I did do the update :( )

    Thursday, August 11, 2011 1:45 PM
  • FYI !! I just uninstalled all Lync updates on the server, rebooted, and was able to set this variable!  Woohoo!


    Damn microsoft patches ..

    Thursday, August 11, 2011 1:55 PM
  • added new virtual server to the pool. old one was removed. the config is stored in the SQL DB. new server installed all the needed packages and applied the config. you can still install the previous patch (april as i remember), i was able to set the variable with no problem.
    Friday, August 12, 2011 6:04 AM
  • Did you send a nice and friendly bugreport to MS? Its nice that we know this may be another new bug introduced in a MS patch, but outside of this thread nobody else may be aware of it.
    Tuesday, August 16, 2011 9:28 AM
  • There is no need to uninstall updates. Instead you can modify xml config file.

    1. Export your configuration to the zip file (Export-CsConfiguration).

    2. Open DocItemSet.xml

    3. At the end of the below string

    <Port Owner="urn:component:QoE" Usage="SipServer" InterfaceSide="Primary" InterfaceNumber="1" Port="5061" Protocol="Mtls" UrlPath="/LiveServer/QoE/" AuthorizesRequests="true" GruuType="QoS" />

    Put following line

    <Port Owner="urn:component:Registrar" Usage="SipServer" InterfaceSide="Primary" InterfaceNumber="1" Port="5060" Protocol="Tcp" UrlPath="/" AuthorizesRequests="false" />

    4. Zip bot files again and import-csconfig.

    5. Run Get-CsService -Registrar this should now show you SipServerTcpPort          : 5060   

    All the syntax in the xml file is case sensitive. Hop this will help you.



    • Proposed as answer by Stuart Carter Friday, November 04, 2011 10:09 AM
    Monday, August 29, 2011 3:33 PM
  • Editing the .XML above does not work either, the system complains:

    WARNING: PortConflictsOnCluster (1) : The topology contains one or more services with port sharing conflicts.
    WARNING: (1) PortNumber "5060" with UrlPath "/" causes a port sharing conflict for IPAddress "" on Machine
    "" for these service ports.
    WARNING:   (1)     ServiceId "", NetPortId "QoE.SipServer.Tcp.Primary"
    WARNING:   (1)     ServiceId "", NetPortId "Mediation.SipClient.Tcp.Pstn"
    Import-CsConfiguration : Invalid topology found in the configuration file "C:\Temp\".
    At line:1 char:23
    + Import-CsConfiguration <<<<  C:\Temp\
        + CategoryInfo          : InvalidData: (C:\Temp\ [Import-CsConfiguration], ArgumentException
        + FullyQualifiedErrorId : InvalidTopologyInImportFile,Microsoft.Rtc.Management.Xds.ImportConfigurationCmdlet


    Has anybody else come across this issue - is there a way to resolve the listening port opening?  Does this only happen on Co-Located servers?


    Ash Cox
    Monday, October 17, 2011 3:21 PM
  • You get this conflict because some other service is listening on 5060. I would check in your topology if you are using 5060 for something else and try netstat to find out which service is using 5060.

    • Proposed as answer by BrettJanzen Thursday, November 10, 2011 9:22 PM
    Wednesday, October 26, 2011 1:03 PM
  • It is only showing as listening against local address

    The actual server node address does have this port open for listening.  Only 444 then 5061, nothing in between.

    Ash Cox
    Thursday, October 27, 2011 7:36 AM
  • I had the same issue as others and exporting the config, modifying the xml and re-importing the config has worked around the issue for me. 

    The only points I would add are:

    1. I did not have the line in the xml that Damian_K mentions but I did have one the same except that the owner was "urn:component:registrar".
    2. I needed to restart my front end service in order for the new configuration to take effect.
    Friday, November 04, 2011 10:11 AM
  • What is your mediation pool TCP listening port set to in Topology Builder? A lot of SIP trunk providers use 5060, which cause the servers to use that port, and will cause the conflict for
    Wednesday, November 30, 2011 1:28 AM
  • I can say that problem is definately related to patches. I had 2 FE's which were updated to latest and 1 archiving server which hasn't updated since a default install of Lync. Above command didn't run on FE's but succesfully ran on archiving server.
    Wednesday, December 21, 2011 2:06 PM
  • I am agree, I have two servers both in test enviroment, one Lync Server has the lastest updates and the command do not work, but the other Lync server do not has updates and the command works fine, the port 5060 is opened.


    Wednesday, January 18, 2012 8:46 PM
  • I don't believe Lync 2010 wants you to change the CSRegistrar SipServer TCP Port. At least for the front end clients, i was reading that the greyed-out radio button that would let you configure unsecure TCP in the past is not supposed to even display anymore. Client to server communication should only work over TLS. Bummer for troubleshooting. I did notice though that you can use an unsecure connection on the back-end "The TCP port of this mediation server must be enabled because a TCP gateway depends on it"
    Tuesday, January 24, 2012 12:24 AM
  • And here is the patch fixing this bug:

    • Proposed as answer by AshCox Wednesday, July 18, 2012 1:29 PM
    Saturday, March 03, 2012 12:30 PM
  • Please help me lync client not sing in

    error:there was a problem verifiying the certificate from the server.

    and aslo logs for client

    Communicator could not connect securely to server because the certificate presented by the server did not match the expected hostname (

    Saturday, June 02, 2012 7:52 AM
  • Different issue - sounds simple to identify however, check your certificates in the topology builder - and then check that you are reaching hostnames that correctly match these certificates.

    You add Subject Alternates too - so you can have more than one supported SIP domain in the same certificate. 

    Ash Cox

    Wednesday, July 18, 2012 1:33 PM