none
Lync 2013 Enterprise Pool Front-End Service don't start

    Question

  • Hi,

    I am deploying na Lync 2013 Enterprise Pool on top of Windows 2012 and the front-end service does not start...it stuks on starting...

    Does somebody experience this behavior...clues?

    here are some errors that i can find at event viewer...

    Failed to sync data for Routing group {2C8E4348-D0A4-54BB-BA22-4C145A99DA96} from backup store.

    Cause: This may indicate a problem with connectivity to backup database or some unknown product issue.

    Resolution:

    Ensure that connectivity to backup database is proper. If the error persists, please contact product support with server traces.

    Server startup is being delayed because fabric pool manager has not finished initial placement of users.

    Currently waiting for routing group: {2C8E4348-D0A4-54BB-BA22-4C145A99DA96}.

    Number of groups potentially not yet placed: 1.

    Total number of groups: 1.

    Cause: This is normal during cold-start of a Pool and during server startup.

    If you continue to see this message many times, it indicates that insufficient number of Front-Ends are available in the Pool.

    Resolution:

    During a cold-start of a large Pool it can take upto an hour for the placement process to finish as it needs to populate all the Front-End databases with data from the Backup Store. If the Pool is running and the Front-End is just started, this is normal for some time. If this repeats for a long time, ensure that all the Front-Ends configured for this Pool are up and running. If multiple Front-Ends have been recently decommissioned, run Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery to enable the Pool to recover from Quorum Loss and make progress

    cheers,


    Vitor

    Thursday, November 8, 2012 5:26 PM

All replies

  • Hi Vitor,

    Do you have more that one front-end in your pool?

    did you executed this command ? ==>

    Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery


    Adrian TUPPER - ABC Systemes - http://thelyncexperience.blog.com/ If answer is helpful, please hit the green arrow on the left, or mark as answer Thank you

    Friday, November 9, 2012 11:01 AM
  • I am having the same issue.  I only have a single server in my Front End pool and I have tried

    Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery and Reset-CsPoolRegistrarState -ResetType fullreset

    Friday, November 9, 2012 4:15 PM
  • Hi, have you upgraded from Lync 2010?

    Also try this:

    Whenever you add Front End Servers to a pool, or remove them from the pool, and then publish the new topology, follow these guidelines:

    • After the new topology has been published, you must restart each Front End Server in the pool. Restart them one at a time.
    • If the entire pool has been down during the configuration change, then run the following cmdlet after the new topology is published:
      Reset-CsPoolRegistrarState -PoolFQDN <PoolFQDN> -ResetType ServiceReset
      

    From http://technet.microsoft.com/en-us/library/gg412996(v=ocs.15).aspx


    Best Regards // Tommy Clarke - Please follow me @ Blog
    and Twitter

    • Proposed as answer by Sanderson5345 Saturday, November 10, 2012 12:12 PM
    • Unproposed as answer by Sanderson5345 Saturday, November 10, 2012 12:12 PM
    • Proposed as answer by Tefty Tuesday, October 15, 2013 8:23 PM
    Saturday, November 10, 2012 12:05 PM
  • I worked with Microsoft and after 4 days discovered that my issue was Server 2012.  MS indicates that Server 2012 fabric services operate differently than 2008R2.  I installed a new front end on Server 2008R2 SP1 and services started with no issues.
    • Proposed as answer by Sanderson5345 Saturday, November 10, 2012 12:14 PM
    • Unproposed as answer by Sanderson5345 Saturday, November 10, 2012 8:05 PM
    Saturday, November 10, 2012 12:14 PM
  • Thats really not a good solution though...

    Please keep the thread open and unmark the answer untill the original threadopener have resolved his problem as well.


    Best Regards // Tommy Clarke - Please follow me @ Blog
    and Twitter

    Saturday, November 10, 2012 12:26 PM
  • Strange. I can believe, that Win2008R2 and Win2012 are somewhat different but this should not affect lync 2013. has MS told you to go back to Win2008R2  instead of finding the root cause and fixing it ?

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Saturday, November 10, 2012 9:21 PM
  • Same error on my side... i am not able to start the lync 2013 rtm front-end Service installed on a Windows 2012 Server!!

    -Andre

    Monday, November 12, 2012 9:32 PM
  • Set the service that does not start to disable.

    Restart the server and when all other services are started set back the service to delayed start. but dont start it.

    Then run Reset-CsPoolRegistrarState -PoolFQDN <PoolFQDN> -ResetType ServiceReset

    The service should now start and after this it should also be able to reboot as usual.


    Best Regards // Tommy Clarke - Please follow me @ Blog
    and Twitter

    Monday, November 12, 2012 9:37 PM
  • does not solve the Problem!

    here some error´s from the eventlog:

    Log Name:      Lync Server
    Source:        LS User Services
    Date:          12.11.2012 22:52:50
    Event ID:      32174
    Task Category: (1006)
    Level:         Warning
    Keywords:      Classic
    User:          N/A
    Computer:      ServerFQDN

    Description:
    Server startup is being delayed because fabric pool manager has not finished initial placement of users.

    Currently waiting for routing group: {4E6F3E79-5291-56A1-988B-103EBA861ABA}.
    Number of groups potentially not yet placed: 1.
    Total number of groups: 1.
    Cause: This is normal during cold-start of a Pool and during server startup.
    If you continue to see this message many times, it indicates that insufficient number of Front-Ends are available in the Pool.
    Resolution:
    During a cold-start of a large Pool it can take upto an hour for the placement process to finish as it needs to populate all the Front-End databases with data from the Backup Store. If the Pool is running and the Front-End is just started, this is normal for some time. If this repeats for a long time, ensure that all the Front-Ends configured for this Pool are up and running. If multiple Front-Ends have been recently decommissioned, run Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery to enable the Pool to recover from Quorum Loss and make progress.

    Log Name:      Lync Server
    Source:        LS User Services
    Date:          12.11.2012 22:53:01
    Event ID:      32178
    Task Category: (1006)
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      ServerFQDN
    Description:
    Failed to sync data for Routing group {4E6F3E79-5291-56A1-988B-103EBA861ABA} from backup store.
    Cause: This may indicate a problem with connectivity to backup database or some unknown product issue.
    Resolution:
    Ensure that connectivity to backup database is proper. If the error persists, please contact product support with server traces.

    -Andre

    Monday, November 12, 2012 10:03 PM
  • Same here. no solution. even starting with disabled services.

    And i'm not alone. 

    i got some feedbacks from other installations hanging at the same point.

    At minimum one has also a PSS Case open. maybe i can tell more later


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Monday, November 12, 2012 11:12 PM
  • Hm i have also seen this in some cases but i think i was wrong on the command, it should be FullReset So it should be the same process but Reset-CsPoolRegistrarState -PoolFqdn "atl-cs-001.litwareinc.com" -ResetType FullReset Please see http://technet.microsoft.com/en-us/library/jj619172(v=ocs.15).aspx. for the details. In Example 4, a full reset is done for the pool atl-cs-001.litwareinc.com. In a full reset, the Front End and Windows Fabric services are stopped and a set of items (including the files LyncServer-MachineSet.xml and Settings.xml) are removed. After these items have been removed, the Front End and Windows Fabric services are restarted. The FullReset option is typically used after topology changes or it unrecoverable errors occur when a pool is started.

    Best Regards // Tommy Clarke - Please follow me @ Blog
    and Twitter



    • Edited by iTommyClarke Monday, November 12, 2012 11:40 PM Stupid ipad formating
    Monday, November 12, 2012 11:33 PM
  • Tried the fullreset as Tommy suggested (after learning the shell needs to be in admin mode) but same issue remains.
    Tuesday, November 13, 2012 4:11 AM
  • I did confirm with Microsoft that using Server 2008R2 is their solution at this time.  They will be investigating the source of the problem on 2012.
    Tuesday, November 13, 2012 10:50 AM
  • We had the same problems during the 2012 RC era.

    Everything worked for Server 2008R2 but not for Server 2012. No on could tell us why.

    We then installed the RTM versions of both products and.... Same issue.

    We were able to start the RTCSRV service twice, after the machine was up for a few hours by running "Enable-CsComputer -Force".

    We still get many errors and it's not working properly. After restarting the server the same issues reappear.

    This is frustrating... Anyone tried installing this in a NEW environment? We have Lync 2010 installed and I was thinking maybe that's a part of the problem. 

    Tuesday, November 13, 2012 12:18 PM
  • same Problem on a new Environment with Server 2012 RTM and Lync 2013 RTM.
    Tuesday, November 13, 2012 3:41 PM
  • I am having the same problem. also using RTM versions for both Windows server 2012 and Lync 2013.
    will be keeping an eye on this forum.

    Edit
    This is on a new environment.

    • Edited by RSudmeijer Tuesday, November 13, 2012 6:14 PM
    Tuesday, November 13, 2012 5:28 PM
  • I'm having the same issue on a new enviroment with server 2012 rtm and lync 2013 rtm.

    Wednesday, November 14, 2012 7:41 AM
  • Just for confirmation. The newest windows updates do not change anything (was expected).


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Wednesday, November 14, 2012 3:49 PM
  • I just tried reinstalling almost all of the features on de front-end server but no go.
    My question to you guys. Did you install the mediation server as colo on the front-end or are you using a seperate Mediation server?

    Just trying to compare server installations to see where the difference is.

    My testlab is the following:
    FE with Med Colo.
    Seperate Edge.
    Seperate MON.

    A colleague of mine has reinstalled everything and got it working. but he did not do anything new as to what he did with the installation before. so we are still stuck.

    Wednesday, November 14, 2012 4:46 PM
  • We have the same problém with Lync Standart edition 2013 and WS 2012.

    Do you have share folder on other drive (D:) your front-end server as we have, and instalation default on C:\Program Files\Lync?

    We have VMWare virtual servers.

    Wednesday, November 14, 2012 7:03 PM
  • My testlab is made in Hyper-V 2012
    Front-end has only one drive (C:\) the share is on this same drive.
    Wednesday, November 14, 2012 10:09 PM
  • Ok lets collect some information. Can you please check the certificates (using the MMC)

    Is the OAUTH Certificate exportable WITH the private key ?
    Is was in my lab but not in a migration lab. requesting the OAUTH Cert again forces to get one with an exportable private key

    Are you using "custom templated" for issuing the certificates ?

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Thursday, November 15, 2012 12:19 AM
  • My OAUTH certificate has been issued by my CA server and has the private key in it.
    I used no custom template when requesting.

    Thursday, November 15, 2012 7:40 AM
  • This would probably not be the problem, since we are able to start the services on the Lync 2013 server running Windows 2008R2 Server.

    This has to do the Windows Server 2012 binaries or settings.


    • Edited by y0av Thursday, November 15, 2012 9:10 AM
    Thursday, November 15, 2012 9:09 AM
  • I've been having the same exact problem trying to stand Lync 2013 up on Server 2012.  Been fighting this for 3 days now.  I finally reinstalled the Front End on a fresh image of Server 2012 and after about the 3rd reboot, the same thing happened again.  

    We're running Virtual, plenty of memory and cpu.  Mediation Server is colocated on the Front End.  Remote SQL 2012.  

     Anyone fixed this yet besides installing on Server 2008?

    Thursday, November 15, 2012 5:58 PM
  • No work around yet, except installing Server 2008R2.

    Still checking with MS here.

    Thursday, November 15, 2012 6:02 PM
  • Should i revert back to 2008R2 for the EDGE as well?  Haven't seen any issues with that or the SQL server that are both running Server 2012.
    Thursday, November 15, 2012 7:41 PM
  • I had the exact same problem!

    But i did as i described in a previous post and it does indid work for me now.

    My setup is a Lync Ent 2013. On Windows Server 2012.

    Did you all try Reset-CsPoolRegistrarState -PoolFqdn "atl-cs-001.litwareinc.com" -ResetType FullReset ????

    Did it NOT work for anyone of you????

    I cant recall that i did anything else than what i posted....


    Best Regards // Tommy Clarke - Please follow me @ Blog
    and Twitter

    • Proposed as answer by EssamKamal Saturday, November 24, 2012 8:31 AM
    Thursday, November 15, 2012 8:08 PM
  • Looking through Microsoft's documentation it looks like they were having the same issue with 'starting' FE. 

    http://technet.microsoft.com/en-us/library/jj205420.aspx

    cfff9385-6bf6-461c-982c-e727c9f20b70

    I also tried going to 2008r2 in which I could get FE to start.  However when I did an in-place upgrade to 2012 it was back to square one with it not starting and all the familiar errors reappearing.


    • Edited by Ozone92 Thursday, November 15, 2012 10:20 PM
    Thursday, November 15, 2012 9:55 PM
  • I'm seeing the exact same issue on Windows 2008 R2 fully updated, Lync Server 2013.

    With one server (with collocated Mediation Server) in a Front End pool, one Edge Server, and the Central Management Store on a SQL Mirror.

    None of the powershell commands above work either.

    I've even wiped everything (removed Schema, and everything under RTC Services in Configuration->Services in ADSI Edit, as well as all databases, files, shares etc) and reinstalled again.. exact same problem.

    Thursday, November 15, 2012 11:35 PM
  • Hi,

    Would you please verify that the CA certificate is located in the Trusted Root CA store on that FE server?Also make sure the display language, input language, format, and location settings on both the Front End server and the Enterprise CA are matched.

    At the same time I have heard some peoples encounter the same issue running Lync server 2013 on Windows server 2012 and the product team is investigating on it.If I have any updates will post here to let you know.  

    Regards,

    Sharon


    Sharon Shen

    TechNet Community Support

    ************************************************************************************************************************

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question.

    Friday, November 16, 2012 8:50 AM
    Moderator
  • Hi Sharon, yes the CA certificate is in the right place, all languages settings identical (cloned from the same VM template), everything had been working fine for days with a small test group.

    I tried to 'enable' a few more users to Lync, and the first symptom I found was that I couldn't set a PIN or edit the user because they were 'not validly homed' on that pool. I had seen that message before, but only for a few seconds whilst it replicated, but this time they never got homed.

    Came back in the next day, and no sign of any change, so I decided to restart the Front End service, and it never came back on. No errors, just the warning about 'Server startup is being delayed because fabric pool manager has not finished initial placement of users'

    I wiped the installation again last night, back to the bone, ADSI-Edit and removed the RTC Service Container, and used LDP to search for any msRTC attributes, re-ran the schema steps (as I'd done before). but this time, I cloned a new VM rather then re-installing on the same machine (but still from the same template), and installed a Standard Edition Front End Pool instead of Enterprise. And so far so good.

    It's a shame to have to use Standard Edition, when there's a decent SQL Mirror in the environment, but there's only one FE server at the moment anyway, it was worth a shot, other option is to go back to Lync Server 2010, or up to Windows Server 2012?

    Friday, November 16, 2012 10:14 AM
  • It's strange

    I played a little bit with certificates and the current situation is.

    Windows 2008R2 CA
    Lync 2013 on Win2012  in coexistence with Lync 2010 (in Win2008R2)

    1. I must have the same langauge settings on Lync and CA to get anything up in general.

    2. the FE starts once after i assing the cert. subsequent starts will fail unti i change the certificate to another one
    Then it also starts "once".

    3. i can change the certifcate back again and again start it once.

    Very strange whats happening here with Windows 2012

    BTW: two more things i found during installation in my lab

    1. the private key of the OAUTH Cert was not exportable. Ooops i requested a new one to solve that but i have not idea, why the initial request was going wrong here

    2. the Default Certs key uasge was only ServerAuthentication. Thats not enough for coexistence with lync 2010. It should also have the clientAuth usage for connecting to the lync 2010 systems.

    Even if it takes a lot of time it is still a challenging learning curve.

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Saturday, November 17, 2012 12:06 AM
  • I am also seeing the exact same problem. Windows 2012 DataCenter, new Lync 2013 Enterprise pool in to an existing Lync 2010 standard environment.

    It had been working for the past day or so. The only significant thing I have done since it was working is deploy a Win2012 and Lync 2013 edge server. But, it may just have been the number of restarts of the FE I have done trying to get that to work that has triggered the failure.

    I have tried the fullreset command.

    Sunday, November 18, 2012 10:10 AM
  • In the end, I added a new 2008 R2 front end server to the Lync 2013 pool, then removed the 2012 front end server in topology builder.

    I forgot for a while to re-run the topology on the edge server, so it was looking for the removed server and had no knowledge of the new. But once that was done, through the setup program, all was fine.

    I'll leave the 2012 server switched off and bring it back in to the topology once MS have fixed, or documented how to fix, this problem.

    The edge server remains as Windows 2012.

    Monday, November 19, 2012 6:57 AM
  • Thats also my current recommended solution.  Wie found out, that it has domething to do with certificates handling on Win2012.

    I issied two certificates per Service (so two for the default cert and two for the OATH)

    After assigning the certificates the services starts but only once. So after stopping the service i have to assign the other certificate and can start them again. 

    Still waiting for a solution.  or stay on Windows 2008R2.  (BTW i do stay there, because i like the "Start"-Button with the classic menu. but is a customer forces Win2012 as Server OS, they have to wait with Lync 2013.

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Monday, November 19, 2012 7:03 AM
  • Hi Everyone.. Just sharing same pain here.. Confirm same results under Lync 2013+WS 2012. Currently asking MS on what to do next.. as soon as anyone has a solution, please post here. Thanks!
    Monday, November 19, 2012 7:09 PM
  • Anyone tried this?

    http://technet.microsoft.com/en-us/library/gg413059.aspx

    Quote:

    warningWarning:
    For Lync Server 2013, KB2713435-x64-RP.msu must be installed on Windows Server 2012 computers before some Lync Server services can be restarted.

    Seems a recent fix to be able to start services under WS2012..

    Greetz!

    Monday, November 19, 2012 8:56 PM
  • I had a breaktrough. Yesterday altough its not beautifull.

    I installed a second front end server. This one starts and works even after reboot.

    i have installed only the frontend server.

    no med colo, no edge because i already have one.

    Just to inform. I was hoping someone else had the same result.

    So in total i have 2 frontends 1 working 1 not. 1 edge. 1 med.

    Tuesday, November 20, 2012 7:20 PM
  • Anyone tried this?

    http://technet.microsoft.com/en-us/library/gg413059.aspx

    Quote:

    warningWarning:
    For Lync Server 2013, KB2713435-x64-RP.msu must be installed on Windows Server 2012 computers before some Lync Server services can be restarted.

    Seems a recent fix to be able to start services under WS2012..

    Greetz!


    Will test this fix tonight on my faulty front-end.
    Tuesday, November 20, 2012 7:25 PM
  • Not working. in my lab

    Hotfix applies only to WIn2012 Preview.  Unable to install on Win2012 RTM.  (Does not apply to this version)

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Wednesday, November 21, 2012 6:20 AM
  • Thank you very much Frank! -- Latest on my Lab: After last FullReset, I gave up for the day, and next morning, the service was Started.. -- Restarted the server to verify error or solution, service gone again.. Couldn´t find any significant events.. Tried replacing certificates, but no luck. Guess We´ll be waiting for MS to answer this..
    Wednesday, November 21, 2012 12:58 PM
  • Hello,

    It appears that everyone on this thread that has a "FE not starting issue" is running an Enterprise pool vs. a Standard Edition "pool"?

    Is that correct?

    Not to throw salt in your wound, but I did not have issues with starting the FE on a Standard Ed Lync 2013 server (pool) running on WS2012.

    If (big if) this is only an "EE FE on WS2012" issue, and for those running only a single EE FE server in the pool, would deploying a single Standard Ed FE server (not EE) be an option since you are running only one FE anyway?

    Sorry to hear you are having problems and good luck with a resolution.

    Stu

    Wednesday, November 21, 2012 4:29 PM
  • Hello,

    My main point is, imo, if the SE bits run on Windows Server 2012 (they do for me), but the EE bits don't (if that is in fact the case; it might not be - I haven't tried), maybe it isn't the O/S that should be ivestigated as the problem? Maybe it is something else? I don't know.

    Just because it works on 2008 R2 and not on Server 2012, imo, I don't think you can make the leap to the conclusion that it must be something wrong with Server 2012, can you?

    Since (I believe) you must install one EE FE before you can install multiple EE FEs, then maybe you weren't planning on stopping with just one EE FE. (I haven't found a way yet to install multiple FEs without installing one first.)   :-)

    In that case, my workaround of installing SE instead of EE might not be a viable solution for you.

    Stu

    Wednesday, November 21, 2012 6:47 PM
  • Lync 2013 SE on Win2012 works fine as long as it is a new setup

    The problem only exists, if you have Lync 2010 in the topology and you install a new Lync 2013 on Win2012 in the same topology. I have feedback from other consultants with Standard and Enterprise and always Migration and win Win2012.

    And i got a Feedback from one guy with an open PSSCall, that is is a problem on of the windows 2012 Server DLLs. It could be fixed by a code change in Lync or in Windows. Lets see whats happening.

    So it looks like the problem is confirmed for now but no solution yet.  Install on Win2008R2 and you are fine.

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Wednesday, November 21, 2012 7:20 PM
  • Thanks for the clarification, Frank.

    Just out of curiosity, the open PSS Call/Case; is that with Windows Server PSS, or with Lync Server 2013 PSS?

    Stu

    Wednesday, November 21, 2012 7:28 PM
  • Not sure. it looks like it is a troubleshooting of various engineers :-). We have to wait..  or start with Win2008R2.

    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Wednesday, November 21, 2012 7:39 PM
  • I'm seeing this same exact problem.   Exisiting 2010 deployment, trying to add a new 2012 server and lync 2013 front end, everything went great until I needed to start the services.   Multiple services will not start.   I hope there is a fix soon!
    • Proposed as answer by EssamKamal Saturday, November 24, 2012 8:30 AM
    • Unproposed as answer by EssamKamal Saturday, November 24, 2012 8:30 AM
    Wednesday, November 21, 2012 9:37 PM
  • Thanks iTommyClarke

    Reset-CsPoolRegistrarState -PoolFqdn "atl-cs-001.litwareinc.com" -ResetType FullReset

    It works with me.

    Saturday, November 24, 2012 8:31 AM
  • I have a Lync 2013 FE server running on Windows 2012 Standard and it worked after multiple reboots.  However, I have the same issue as everyone else after I upgraded my Lync 2013 Edge Server from Windows 2008 R2 to Windows 2012.  Although the health and performance of the Edge server are fine, I rebooted my Lync FE Server and have the same issue.

    Since my environment is virtual, I am reverting my Edge Server back to Windows 2008 R2 with Lync 2013 to see if that make any difference.  I hope this proves correct, as I have been running Lync 2013 for two weeks and have rebooted each Server multiple times.  My theory is as long as there is a Windows 2008 R2 server somewhere in the mix, all is well.  I am in the process of trying this out and will report my results...

    Sunday, November 25, 2012 11:52 PM
  • Hi All,

    No Dice.  I also tried running Reset-CsPoolRegistrarState -PoolFqdn "fe.domain.com" -ResetType FullReset and re-assigning the certificates on the FE.

    Guess we will all wait...

    Monday, November 26, 2012 12:35 AM
  • I have installed a completely fresh Win 2012 Server and installed Standard Edition 2013 Lync server, and still have this exact issue - The FE service will not start. I too get the error stating 'insufficient number of Front-Ends are available in the pool'

    They have never used Lync at this company so it cannot be an issue with an upgrade or conflict with an old version.  I used OCS 2007 in my previous employment with no issues whatsoever.

    I have only enabled 1 single user, so I can't not have enough FE servers available!

    Have re-imported certificates from local domain CA and tried every other suggestion on this post

    Thursday, November 29, 2012 3:15 PM
  • Yea, I am having the exact same issues.  However, I did notices something really weird.  I did not have the any of the issues of services not start starting until I install the Edge server.  Once the Edge Server went on I was no longer able to get the Lync Front end service up and running after that.

    XenServer 6.1

    Server 2012 Dc

    Lync 2013 server with FE

    Lync 2013 EdgeServer

    The only thing that appeared in the Lync Server log is Event ID: 61043 Source LS MCU infrastructure.  Is there an update on this issue?

    Monday, December 3, 2012 5:47 AM
  • I also experienced the same issue after a power outage.  Have a Lync 2010 deployment with Lync 2013  consisting of one Director, FE Pool(collocated Med server), SQL 2012 BE, Group Chat Server, WAS server all running with Windows 2012. Both the FE service on the FE and Director would be in a persistent starting state along with the various event log messages described in this thread.

    Ran through all the suggestions: Reset-csPoolRegistrarState -PoolFQDN <PoolFQDN> -ResetType fullreset a couple of times. Tried changing out the certificate and running setx /m FabricPackageFileName ".  Went ahead and applied Windows updates specifically an update to .net Framework 4.5. Nothing seemed to work. 

    On the FE server I decided to stop the services in order starting with the Application sharing service, Lync Server Audio Test Service, Lync Audio/Video Conferencing service and viola the FE service started and I subsequently restarted the other services and the Director FE service started without an issue as well. 

    Can't pin pinpoint the exact combination of actions but the information in this thread helped me.

    Thank you

    -PG-

     
    Tuesday, December 4, 2012 7:22 AM
  • I worked with Microsoft and after 4 days discovered that my issue was Server 2012.  MS indicates that Server 2012 fabric services operate differently than 2008R2.  I installed a new front end on Server 2008R2 SP1 and services started with no issues.

    @ Sanderson5345
    You say you have worked with Microsoft Support. Do you maybe a support number that we can exchange.
    I have created a paid support ticket for our company yesterday for the same issue. if we could exchange ticket numbers the Microsoft support engineers could maybe work together.
    please mail me at:  roy at startready.com

    Regards,

    Roy
    StartReady


    • Edited by RSudmeijer Thursday, December 6, 2012 6:54 PM
    Thursday, December 6, 2012 6:52 PM
  • As this seems to apply to "upgrades" only and reading between the lines of the above, is it fair to say that this issue only surfaces when you assign a Server 2012 edge to your 2013 pool?

    Prior to doing that, if you are following the MS instructions, your Lync 2013 on Server 2012 FE server would be talking to the existing Lync 2010 Edge on Server 2008. And I *think* from the above, whilst this is the case, the 2012 FE works fine.

    I imagine for most people, replacing the edge with the new version would be the last job you do. And maybe it is then that the problem surfaces.

    I cannot be exactly sure of the sequence of events with me, but I think the above is quite likely what happened. I cannot imagine that I would not have noticed the problem on the FE sooner otherwise.

    Thursday, December 6, 2012 8:02 PM
  • As this seems to apply to "upgrades" only and reading between the lines of the above, is it fair to say that this issue only surfaces when you assign a Server 2012 edge to your 2013 pool?

    Prior to doing that, if you are following the MS instructions, your Lync 2013 on Server 2012 FE server would be talking to the existing Lync 2010 Edge on Server 2008. And I *think* from the above, whilst this is the case, the 2012 FE works fine.

    I imagine for most people, replacing the edge with the new version would be the last job you do. And maybe it is then that the problem surfaces.

    I cannot be exactly sure of the sequence of events with me, but I think the above is quite likely what happened. I cannot imagine that I would not have noticed the problem on the FE sooner otherwise.

    This is not true.  I have a server 2012 Domain with a CA.  I re-issued my certs internally and correct a few of my issues.  I had applied the certs wrong to begin with.  However, once the Edge server went up and I fixed the Cert issue there I still can't get the Lync Server front-end service to start.

    I have done the following commands

    Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery 

    Reset-CsPoolRegistrarState -PoolFqdn "atl-cs-001.litwareinc.com" -ResetType FullReset

    The service still refused to come up.  I am not getting any feed back in logs one way or the other now.


    • Proposed as answer by ArgiDio Tuesday, March 5, 2013 12:10 PM
    Thursday, December 6, 2012 10:00 PM
  • As this seems to apply to "upgrades" only and reading between the lines of the above, is it fair to say that this issue only surfaces when you assign a Server 2012 edge to your 2013 pool?

    Prior to doing that, if you are following the MS instructions, your Lync 2013 on Server 2012 FE server would be talking to the existing Lync 2010 Edge on Server 2008. And I *think* from the above, whilst this is the case, the 2012 FE works fine.

    I imagine for most people, replacing the edge with the new version would be the last job you do. And maybe it is then that the problem surfaces.

    I cannot be exactly sure of the sequence of events with me, but I think the above is quite likely what happened. I cannot imagine that I would not have noticed the problem on the FE sooner otherwise.


    Also this problem applies to Fresh installs on environments that did not have lync before.
    So new 2012 servers with Lync 2013 freshly installed.
    Thursday, December 6, 2012 10:24 PM
  • As this seems to apply to "upgrades" only and reading between the lines of the above, is it fair to say that this issue only surfaces when you assign a Server 2012 edge to your 2013 pool?

    Prior to doing that, if you are following the MS instructions, your Lync 2013 on Server 2012 FE server would be talking to the existing Lync 2010 Edge on Server 2008. And I *think* from the above, whilst this is the case, the 2012 FE works fine.

    I imagine for most people, replacing the edge with the new version would be the last job you do. And maybe it is then that the problem surfaces.

    I cannot be exactly sure of the sequence of events with me, but I think the above is quite likely what happened. I cannot imagine that I would not have noticed the problem on the FE sooner otherwise.


    Also this problem applies to Fresh installs on environments that did not have lync before.
    So new 2012 servers with Lync 2013 freshly installed.

    yes, I have fresh install of 2012 in virtual environment new domain 2 GPO's applied.  This is definitely got something to do more with 2012 server than it does Lync or certs right at the moment.  Technically so to speak this should be working.

    I guess I will install 2010 server to see if I can get it working. 

    Thursday, December 6, 2012 10:40 PM
  • It looks like the problem is there with Lync 2010 coexisting.

    But Updateing the Edge is not the first you you do ! Normally the Lync 2013 FE-Pool is deployed first.
    then you deploy your new Lync 2013 Edge besides (witih new names) and switch the users. but the old Edge will still act as federation route.  And somewhat later you switch the Edge to lync 2013.

    The problem IS there with a Lync 2010 Pool and a Lync 2010 Edge in the topology (no Lync 2013 Edge yet).

    I agree with you, that the problem looks like "new". but it did not happen on Win2012 RC. and al i know for now is, that ir might be a problem with Lync and the http.sys module of windows.

    Maybe a newer Windows 2012 Update will fix some thing.....

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Thursday, December 6, 2012 11:42 PM
  • Today I have talked to the Microsoft engineer and he told me that it could be indeed a Windows server 2012 issue. He had found another ticket that had the same issue and was told that a developers team was gathered to figure this problem out. I will hear more from them on Monday.
    Friday, December 7, 2012 11:09 PM
  • It looks like the problem is there with Lync 2010 coexisting.

    But Updateing the Edge is not the first you you do ! Normally the Lync 2013 FE-Pool is deployed first.

    I thought that is what I said ! This is what I did. I created a new 2013 pool using a 2012 server and linked it to the existing (2008R2/2010) edge, I migrated some test users to the new pool, which worked fine. Then I deployed a new Lync 2013 edge also on Server 2012 and added it to the topology. As all seemed to be working up until this point, I assigned the new edge server to the new FE. At some point during this process, the 2012 FE stopped working with the problem described in this thread. It may well be though that the problem was waiting to happen before that, but only after a restart of the FE service (or the server) did it surface.

    To work around, I installed yet another 2013 FE server, but this time on 2008 R2 and added it to the same pool. I removed the 2012 based FE from the topology. I am now left with a completely 2013 pool in production, with the edge on Server 2012 and the FE on 2008 R2.

    I recently removed all of the Lync 2010 server from the topology completely and, to my knowledge, all is working well.

    If I get around to it, now that all of Lync 2010 has been decommissioned, I will try bringing the 2012 FE back in to the topology to see what happens to it!
    • Edited by ScottB_555 Saturday, December 8, 2012 2:36 PM
    Saturday, December 8, 2012 2:33 PM
  • Here's an interesting update.

    A quick recap on the setup:

    All severs running Lync 2013. No Lync 2010 left, although users were migrated from an original Lync 2010 pool, since decommissioned.

    Single enterprise FE in pool running Windows 2008 R2.

    Edge server running Server 2012.

    Today I added a second server to the FE pool. It was a fresh build server 2012.

    After adding the new FE to the topology and installing Lync, I restarted all of the servers. This time I got all of the same errors on the front end service as above but on the *existing 2008 server*. Yes, that wouldn't start now. This server has been working fine for a couple of weeks or more.

    So I powered down completely the new Server 2012 FE and rebooted the 2008. The 2008 took a long time about it, complaining about how it is now the primary front end for various routing groups and problems with quorum etc, but the FE service eventually started. I then switched on the 2012 server and that started up too.

    Just to make sure this wasn't a fluke, I rebooted the 2012 server a few times, but every time the FE service would start.

    So, I figure one of two causes. The 2012 server cannot be the primary front end, or it puts some "junk" in the database that only 2008 can sort out.

    I am going to have to play with it some more to be sure. The next test will be to down the 2008 box and reboot the 2012 server and see what happens then!

    Monday, December 10, 2012 11:19 PM
  • Adding a me too on this.

    Lync 2010 Pool running OK.

    Added a Lync 2013 Standard Server on Win 2012 and hit the exact issue in this thread immediately. None of the suggestions have helped. I'm going to rebuild on Win 2008 R2 as I need to demo Lync 2013 next week.

    A test single Lync 2013 Standard Server on Win 2012 is fine though.

    Rick

    Tuesday, December 11, 2012 3:15 PM
  • ok Today i got a reply from the microsoft engineer.

    I had to try the following. please note this will lower security so i dont know know if this has any security impact for server 2012 and Lync. and if this will be the fix that microsoft will offer. but the solution works for testing until further notice.

    On the Front-End server create the following registry:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

    create a registry key named ClientAuthTrustMode and set value to 2.

    Restart the machine after making the changes.
    Once the server is restarted check if the service is started or wait for some time for it to start.

    Cheers!


    • Proposed as answer by RSudmeijer Tuesday, December 11, 2012 9:08 PM
    • Edited by RSudmeijer Tuesday, December 11, 2012 9:09 PM
    Tuesday, December 11, 2012 9:08 PM
  • RSudmeijer's suggestion worked for me. 
    Wednesday, December 12, 2012 6:14 AM
  • +1  works for me, too

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Wednesday, December 12, 2012 7:43 AM
  • Excellent, the reg key worked for me too. Many thanks.
    Wednesday, December 12, 2012 2:36 PM
  • Just talked to the engineer.

    The solution is not final. he did tell me that this should not be used in production environments.
    Will get more info after this week.

    Wednesday, December 12, 2012 4:34 PM
  • Hi,

    Thanks for the update. A few follow-up questions please?

       - What app reads this registry key?

       - What does this value of 2 for this registry key do?

       - Why should this **not** be used in a production environment (i.e. one connected to the internet)?

    Thanks.

    Stu

    Wednesday, December 12, 2012 5:07 PM
  • SCHANNEL is a component of the Windows OS, which can be used by applications to to all the TLS Stuff.

    The regKey is read by the SCHANNEL.DLL as i know

    Unfortunaly i have not found anything documented about ClientAuthTrustMode
    On http://msdn.microsoft.com/en-us/library/cc949005.aspx you can find:

    Additionally, a certificate revocation list (CRL) validation is performed during certificate authentication. This validation checks the list of certificates that were revoked by the root certificate. Three modes of revocation exist:

    • Online. The CRL list is retrieved and checked online, requiring connectivity to the computer that contains the CRL.
    • Offline. The CRL list is retrieved and checked online and is then cached offline for subsequent validation.
    • NoCheck. No validation is performed

    I assume, that this key simply disables some checks of the certificate. So in a secure world, this is not a good idea to disable such checks. Lets wait for the final solution.

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Wednesday, December 12, 2012 6:12 PM
  • Thanks for your reply Frank.

    From your response, I interpret you to say that:

       1. This registry key only has an effect on applications ("does something") that actually look for the registry key, and have code to do something based on the value of that registry key.

       2. You assume that this registry key disables "certificate checks" (presumably by the Lync FE) (the "does somehting" above in #1).

    Please correct me if I misunderstand your explanation.

    Any idea when the final solution we are waiting for might be forthcoming? Sorry, I tend to be an inpatient sort. :-)

    Thanks again for your reply.

    Stu

    Wednesday, December 12, 2012 6:35 PM
  • As I said I will know more in a few days or else next week.
    Wednesday, December 12, 2012 8:16 PM
  • Thanks RSudmeijer.

    Actually, my deployment (test, not production) is working just fine without this registry .... "tweak".

    I ask only for those who might want to deploy Lync 2013 in production, and might not want to implement this "tweak".

    Thanks again.

    Stu

    Wednesday, December 12, 2012 8:28 PM
  • Hello,

    we had also this problem. The key is working for us too.

    We have also an ongoing Prio A support call with  Microsoft. I asked my support engineer when we will get a final solution. I will inform you when I get a response.

    Thanks,

    Sven

    Wednesday, December 12, 2012 10:26 PM
  • Thanks Sven.

    Stu

    Wednesday, December 12, 2012 10:36 PM
  • I did a fresh install of Lync 2013 Ent pool on Win2008 r2 SP1 in our environment. As soon as I add second FE server to the pool, the FE service is not starting on either of them. If I disable the FE service on second server, then first server works with no issues. I have opened a case and waiting to hear from engineer. I will update once I get some answer.
    Thursday, December 13, 2012 2:27 AM
  • Thanks RSudmeijer.

    Actually, my deployment (test, not production) is working just fine without this registry .... "tweak".

    I ask only for those who might want to deploy Lync 2013 in production, and might not want to implement this "tweak".

    Thanks again.

    Stu

    We are also waiting for a final conclusion because we dont want to use this kind of workaround in a production environment.


    • Edited by RSudmeijer Thursday, December 13, 2012 2:38 PM different word
    Thursday, December 13, 2012 2:37 PM
  • The key doesn't work for us. Maybe because the languages binaries of Lync 2013 are in Spanish and WS2012 are in English. Will try all in English with the registry Key.

    Scenario: Migration from Lync 2010 SE With MedSrv/WS2K8R2, Lync Edge 2010/WS2K8R2. Physical Server Lync 2013 SE With MedSvr/WS2012


    Sergio Argüello Productivity Solutions Engineer Interconnect SA

    Thursday, December 13, 2012 6:35 PM
  • Hello,

    here are some more information I have got from my support case about the issue:

    This occurs because Schannel connections are failing in case of mutual authentication (client as well as server). What is happening is that the trusted issuers list for credential group on the server side doesn’t contain the issuer of the client’s certificate. In Windows 2012, Schannel while evaluating client policy looks for the value of ClientAuthTrustMode which it gets from registry: HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel Key, “ClientAuthTrustMode” DWORD Value.

    It can take values between 0-2. By Default this registry is not present in the system which means that ClientAuthTrustMode is set to Machine trust.

    0         : Machine Trust

    1         : Exclusive Root Trust

    2         : ExclusiveCATrust

     For Machine and Exclusive Root Trust states, on server side, Schannel compares the issuers of all the certificates in the client certificate chain and compares with the Trusted Issuers List it has.

    In Windows 2008 R2, this logic of trust levels is not present and hence there is no issue there

    The  Product Group is working towards this to ascertain if there are any negative security implications associated with this workaround but there is no ETA on this.  

    When I will get more Information I will add it to this thread.

    Sven

    Thursday, December 13, 2012 7:36 PM
  • Thanks Sven. Great summary.

    Re: In Windows 2008 R2, this logic of trust levels is not present and hence there is no issue there

    But I don't think this logic exists in Windows Server 2012 either, does it? I think the logic exists in the application(s) reading the key ("0" if it doesn't exist as Sven mentions).

    1. For those who *have* had problems starting the FE, do you have Lync Server 2013 server roles on more than one server instance (physical or virtual)?

    2. For those of you that are *not* having problems starting the FE, do you have all Lync Server 2013 server roles on a single server instance? I do and it works for me (Lync 2013 on WinServer 2013, all server roles on the same server instance).

    Based on all of the above posts, I think it is a problem with communication between multiple Lync server roles (TLS) that meet both the following 2 conditions, in my opinion:

       1. One Lync 2013 FE

       2. At least one other Lync 2013 server role on a different server instance.

    Does this hold true for everyone? Or, a better question, who does this not hold true for?

    Thanks.

    Stu

    Re: In Windows 2008 R2, this logic of trust levels is not present and hence there is no issue there

    Thursday, December 13, 2012 9:18 PM
  • In Windows 2008 R2, I have noticed the same Schannel errors. I have two certificates (FE pool cert and OAuth cert) in computer personal store. Then I removed separate OAuth certificate from store and assigned FE pool certificate as the OAuth cert. Started FE service with issues and no more schannel errors.

    I have two FE servers on virtual instance. 

    Friday, December 14, 2012 1:03 AM
  • Hello,

    Actually, my FE failed to start today, so this is no longer true for me.  :-)

    I have KB931125 (optional) Update for Root Certs installed. (Do you?)

    This solved the problem (without the other registry hack) on my test deployment:

    1. I checked my Trusted Root Cert for Computer and saw a .... ton of Trusted CAs.(Do you?)

    I did this after changing the value of the EventLogging key at:

         HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel Key

    to 3 in lieu of it's default.

    2. It complained that there were too many truted Root CAs to handle.

    3. I deleted all the CAs except my domain (fabrikam) and FE Server Certs

    4. I rebooted.

    The FE started again.

    Stu

    Friday, December 14, 2012 1:08 AM
  • Hi Surya,

    Check the Trusted Root Certification Authorities Certificates folder for the computer account on your FE.

    That is where I found the numerous trusted CAs listed; not the Personal Certificates folder.

    Stu

    Friday, December 14, 2012 1:38 AM
  • Hello,

    here are some more information I have got from my support case about the issue:

    This occurs because Schannel connections are failing in case of mutual authentication (client as well as server). What is happening is that the trusted issuers list for credential group on the server side doesn’t contain the issuer of the client’s certificate. In Windows 2012, Schannel while evaluating client policy looks for the value of ClientAuthTrustMode which it gets from registry: HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel Key, “ClientAuthTrustMode” DWORD Value.

    It can take values between 0-2. By Default this registry is not present in the system which means that ClientAuthTrustMode is set to Machine trust.

    0         : Machine Trust

    1         : Exclusive Root Trust

    2         : ExclusiveCATrust

     For Machine and Exclusive Root Trust states, on server side, Schannel compares the issuers of all the certificates in the client certificate chain and compares with the Trusted Issuers List it has.

    In Windows 2008 R2, this logic of trust levels is not present and hence there is no issue there

    The  Product Group is working towards this to ascertain if there are any negative security implications associated with this workaround but there is no ETA on this.  

    When I will get more Information I will add it to this thread.

    Sven


    Nice explaination!
    Friday, December 14, 2012 7:04 AM
  • Very nice explanation.

    Does others have this KB931125? What is it and do I needed it for the lync?

    Alice

    Friday, December 14, 2012 4:29 PM
  • Hi Alice

    Please see http://social.technet.microsoft.com/Forums/nl-BE/winserveressentials/thread/2636b892-7113-4692-a4f4-53d330ca6062

    Stu

    Friday, December 14, 2012 5:15 PM
  • ...and http://support.microsoft.com/kb/2464556

    Stu

    Friday, December 14, 2012 5:27 PM
  • Hello Stu,

    Thank you for your response. Yes, I have applied KB931125 and there are ton of Trusted Root CAs. I did not delete any of the Trusted Root CAs nor created the registry key mentioned in article http://support.microsoft.com/kb/2464556. Surprisingly the FE services are running with no errors. Every now and then, there are 36885 events in System log. I will delete few Root CAs instead of registry key.    

    -Surya

    Friday, December 14, 2012 9:25 PM
  • Not quite for me:

    WORKS: Single Std Server in a test domain. No Edge.

    DIDN'T WORK (needed the reg hack to fix): Added a 2013 Std Server into a domain with a single 2010 FE, 2010 Edge.

    Saturday, December 15, 2012 12:20 AM
  • The ClientAuthTrustMode import worked first time for me!  I got this error from a fresh 2013 FE installed on 2012 using a 2012 DC, DNS & Cert Auth (No edge yet though).  I'd tried numerous fixes dotted around the forums but this moves my testing on!

    Many Thanks!  Will keep an eye out for the production fixes...

    Monday, December 17, 2012 12:45 PM
  • For ClientAuthTrustMode do you just need to create that registry key on the front end servers? What DWORD value should it be given?

    Tuesday, December 18, 2012 8:46 AM
  • Thanks RSudmeijer. 

    This worked for me.  I had to add the ClientAuthTrustMode value to my new edge server also in order to get it to replicate successfully.  I am still seeing the 36885 events in the System event log after adding the SendTrustedIssuerList value and setting it to zero.  I would have expected that the servers would stop logging this.


    • Edited by CJADuva Wednesday, December 26, 2012 4:08 PM Additional info
    Tuesday, December 18, 2012 6:37 PM
  • Ok good news.  A solution is found and Microsoft will publish a KB-Article about that

    It should be availible that week at http://support.microsoft.com/kb/2795828

    Check that the root certificate store contains only ROOT Certs
    Check the intermediate Certificate store contains only Intermediate Certs.

    And we should see a Blog Post soon from the engineer. 

    So if you have time to wait, then go shopping and come back later.

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    • Proposed as answer by Rick Eveleigh Tuesday, March 5, 2013 3:02 PM
    Tuesday, December 18, 2012 8:26 PM
  • Since the December 2012 version of the KB931125 appears to have been pulled (I can't find it anymore), it would be nice, imo, if that KB included a list of changes made by KB931125 (Dec '12), so that the server can be restored (albeit manually) to a state prior to taking the KB931125 update. (Since the KB931125 says it can't be uninstalled.)

    I believe this would be especially "nice" for production environments, since I would expect that those servers have many more Certs (Root and/or Intermediate) than test environment servers, imo.

    Stu

    Tuesday, December 18, 2012 9:00 PM
  • Two thing.

    1. Feedback to my former Post. I cleaned up my certificate stores to have RootCerts in the RootStore only and intermediate in the intermediate only etc and my FE is starting now without problems.

    2. the KB931125 is a 365kb (?) installer to add additional trusted roots to the PC. In the old (win2000/) days, this was the only official way to add trusted roots to the OS. It is no longer required, because windows can grab required root certs automatically

    Event ID 11 — Automatic Root Certificates Update Configuration http://technet.microsoft.com/en-us/library/cc734018(WS.10).aspx

    Certificate Support and the Update Root Certificates Component
    http://technet.microsoft.com/en-us/library/bb457160.aspx
    http://technet.microsoft.com/en-us/library/cc733922(WS.10).aspx

    But this works ONLY, if the server (or nearly every PC) can connect to sites at microsoft to dorwnload the required root cert als Computername$ (if your proxy requires authentication. I know a lot of test fields and even production where servers cannot access the internet (nut a bad design at all). So you can still use that update to "preload" additional roots to your server which are downloaded dynamically otherwise.

    You can test that easily: Install a fresh new Win2008/Win7 box and check the root certs. ONly a few are there. No surf around using SSL to various sites and you can see the number growing :-)

    A long RootCert List can trigger other problem: See Event 36885

       

    So it loks like the "only" (and solvable) problem are certificates in the "wrong" storage. Cleanup your computer certificates and you are done.

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Wednesday, December 19, 2012 5:18 AM
  • Apparently, the way I read http://support.microsoft.com/kb/931125 (12/21/12 Revision Note), is that it is my irresponsibility in not confirming that the update for KB931125 didn't exceed the maximum number of certs, that is the cause of my FE not starting.

    ...<snip>...

    "Server Administrators who install the root update package on Windows Server SKUs bear the responsibility for making sure that the certificate count does not exceed the limits* described in KB 933430 and KB 931125.  

    Some customers did not follow the guidelines published in KB 931125 before they installed the latest update from WU or WSUS, and they encountered the issue documented in KB 933430. For this reason, the KB 931125 updates for Server SKUs were expired from WSUS on 12/21/12."

    ...<snip>...

    For the full reprimand (imo) and lecture, see: http://support.microsoft.com/kb/931125.

    Really?!?! 

    No...Seriously?!?!

    Stu

    PS Happy Holidays

    Sunday, December 23, 2012 10:37 PM
  • In the meantime that KB is not published there is a draft available on blog of Microsoft engineer that worked on this problem: http://blogs.technet.com/b/lync_tips_and_tricks/archive/2012/12/21/lync-2013-not-starting-on-windows-2012.aspx

    If you are deploying Lync 2013 on Windows 2012 you may encounter one of the following issues 

    1. Lync 2013 Front End Service RTCSRV failing to start 
    2. HTTPs connectivity failures reported in the event viewer [we will add some events here for reference:

    Event 30988, Ls User Services

    Sending HTTP request failed. Server functionality will be affected if messages are failing consistently.

    Sending the message to https://URL.contoso.com:444/LiveServer/Replication failed. IP Address is 192.168.0.1. Error code is 2EFE. Content-Type is application/replication+xml. Http Error Code is 0.
    Cause: Network connectivity issues or an incorrectly configured certificate on the destination server. Check the eventlog description for more information.
    Resolution:
    Check the destination server to see that it is listening on the same URI and it has certificate configured for MTLS. Other reasons might be network connectivity issues between the two servers.

    clip_image001[4]

    Event 32178, LS User Services

    Failed to sync data for Routing group {EB10E520-9B20-575D-9D4C-C06E5A937F65} from backup store.
    Cause: This may indicate a problem with connectivity to backup database or some unknown product issue.
    Resolution:
    Ensure that connectivity to backup database is proper. If the error persists, please contact product support with server traces.

    clip_image001[7]

    Event 32174, LS User Services

    Server startup is being delayed because fabric pool manager has not finished initial placement of users.

    Currently waiting for routing group: {EB10E520-9B20-575D-9D4C-C06E5A937F65}.
    Number of groups potentially not yet placed: 1.
    Total number of groups: 1.
    Cause: This is normal during cold-start of a Pool and during server startup.
    If you continue to see this message many times, it indicates that insufficient number of Front-Ends are available in the Pool.
    Resolution:
    During a cold-start of a large Pool it can take upto an hour for the placement process to finish as it needs to populate all the Front-End databases with data from the Backup Store. If the Pool is running and the Front-End is just started, this is normal for some time. If this repeats for a long time, ensure that all the Front-Ends configured for this Pool are up and running. If multiple Front-Ends have been recently decommissioned, run Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery to enable the Pool to recover from Quorum Loss and make progress.

    image

    Cause:

    You are likely to hit one of these issues if you have deployed non self-signed certificates into Trusted Root Certification Authorities instead of Intermediate Certification Authorities. This is a misconfiguration and can cause HTTP communication between Lync servers to be broken with untrusted root cert error. In Windows 2012 there is a high level of trust check for certification authentication, and hence this issue is exposed only for Lync deployments on Windows 2012.

    Resolution:

    You can follow the following steps to fix such misconfigurations: 
    1. If you are using group policies to deploy certs (
    http://technet.microsoft.com/en-us/library/cc738131(v=WS.10).aspx) ensure Trusted Root Certification Authorities only contains self-signed certificates (where Issued To = Issued By). Move any non-self-signed certificate present in this store to Intermediate Certification Authorities 
    2. If you are importing any new certificates (either on your DC or Windows 2012 machines), then ensure as part of import you choose Trusted Root Certification Authorities for any self-signed certificates and Intermediate Certification Authorities for any non-self-signed ones


    Wednesday, January 2, 2013 10:37 AM
  • it worked for me as well many thanks for the registry hint

    Thursday, January 3, 2013 12:11 PM
  • You DO NOT NEED the registry Key anymore, if you cleanup the local certificate stores.

    see http://blogs.technet.com/b/lync_tips_and_tricks/archive/2012/12/21/lync-2013-not-starting-on-windows-2012.aspx


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    • Proposed as answer by Rick Eveleigh Friday, January 4, 2013 3:18 PM
    Thursday, January 3, 2013 12:45 PM
  • Can you elaborate a bit more on how to cleanup the local certificate stores?

    All the certs installed by KB931125 appear to have Issued To = Issued By.

    Friday, January 4, 2013 12:39 AM
  • The Basic things.

    1. the Root certificate store should only contain ROOT Certs (not intermediate or others)

    2. the number of the Root Certs should not exceed the SCHANNEL limits.

    3. Intermediate certificates should be in the corresponding zertificate container.

    Thats all. All my Lync 2013 Servers on Win2012 with the "Start Problem" are running now after moving certificates to the "right" store.


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Friday, January 4, 2013 9:15 AM
  • Have a look at http://support.microsoft.com/kb/2464556 for tips on how to clean up the Trusted Root Cert list.
    Friday, January 4, 2013 3:19 PM
  • Thanks. I was using the registry entry. Reverted it to 1 from 0, cleaned up the Trusted Root Certificate List (following http://support.microsoft.com/kb/2464556) but the service still wouldn't start. However I had two items left in the list where Issued To did not = Issued By. Moved these to Intermediate, reboot and the service starts.
    Friday, January 4, 2013 3:21 PM

  • The documentation states that Certs issued from a Public CA are supported for the Lync 2013 FE.

    The documentation states that the Lync 2013 FE cert must be installed to the Trusted Root CA store.

    For certs from a Public CA, does Issued To == Issued From? I don't think so.

    So, are certs from a Public CA not supported now?

    Friday, January 4, 2013 6:17 PM
  • Your statement is parially correct.

    Think about a "CA".  (it doesnt' matter if it is public or private). Public means it is trusted by many systems word wide and a private CA is normally an internal CA, which is not trusted outside of your organization.
    But a CA is a CA and works as long as it is trusted (and the CRL can be validated etc)
    You have to pay for a certificate from a "Public CA".

    Lync supports certificates which are issued by any CA and the certificate chain must be valid. so

    1. YES, you can use Certs from a "public CA"  without any problems.
    BUT you must be sure that the RootCert of your CertificateChain is in the trustedRootStore of the computer and any system which connects to your server
    AND you must be sure, that any intermediateCA in the chain must be in the intermediateStore of your server. AND ONLY THERE.  so not in the RootStore of your server

    2. Do you have a link for your second statement, that the Lync 2013 FE Cert must be in the RootStore. ? this i not true !!

    3. Every RootCert is a "Self signed" certificate. and i have >300 RootCAs on my Desktop (NOT SERVER !!!) and all have a  IssuedBy=IssuedTo.

    So if you have a cert not working like that, it might be a intermediate and should be moved from the RootStore to the intermediate Store. And thats the problem, why Lync 2013 does not start on Win2012

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Friday, January 4, 2013 6:29 PM
  • From the LyncITPro CHM (LyncServer2013_ITPro.chm::/html/e12e59b5-a146-4859-86ec-cabfc198c7b5.htm)

    16. On the Online Certificate Request Status page, review the information returned. You should note that the certificate was issued and installed into the local certificate store. If it is reported as having been issued and installed, but is not valid, ensure that the CA root certificate has been installed in the server’s Trusted Root CA store. Refer to your CA documentation on how to retrieve a Trusted Root CA certificate. If you need to view the retrieved certificate, click View Certificate Details. By default, the check box for Assign the certificate to Lync Server certificate usages is checked. If you want to manually assign the certificate, clear the check box, and then click Finish.

    Friday, January 4, 2013 6:33 PM
  • You have to read the words carefully.

    One parts talks about the FE Certificate:

    "... You should note that the certificate was issued and installed into the local certificate store...".

    the "Local certificate store" is NOT the "local root certificate store".  this is the "local personal certificate store" of the local computer.

    And and the second part talks about the Root:

    "...If it is reported as having been issued and installed, but is not valid, ensure that the CA certificate has been installed in the server’s CA store" the important work here is "CA Certificates".  this is the cert of the issuing CA and not the FE-Certificate.

    So this text block does not tell you anything wrong. But is only not complete, because it does not tell you how to store the certs of the intermediateCA.

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Friday, January 4, 2013 6:55 PM
  • We removed all unneeded root certificates from trustedRootStore of the Lync Server 2013 (on Windows Server 2012) and Lync Server now started for the first time of its life!

    It was long long way to the solution...

    Friday, January 4, 2013 6:56 PM
  • So why did Microsoft (via KB931125) install all those Certs in the Trusted Root store that exceeded the limit and caused the server to not start?

    Also, from your post:

    Lync supports certificates which are issued by any CA and the certificate chain must be valid. so

    1. YES, you can use Certs from a "public CA"  without any problems.
    BUT you must be sure that the RootCert of your CertificateChain is in the trustedRootStore of the computer and any system which connects to your server

    If the Root Cert is from a public CA, then (Issued To == Issued From) is False, not True, isn't it?


    Friday, January 4, 2013 7:13 PM
  • The Update "KB931125 Update for Root Certificates For Windows XP [December 2012]" was updated. It was a "WSUS/Windows Update" error. This updates should only be appied on Windows Clients but not servers.

    Check your root Certs in the computers root certificate store. you should see, that alle Root CAs are issued by the rootca itself. and thats how it is.

    My statement about "BUT you must be sure that the RootCert of your CertificateChain is in the trustedRootStore of the computer and any system which connects to your server" is about the following:

    The most Servers have only a small subset pof "public CAs". Install Win2008/2012 and check the root cert store. You will only find a "few". But Windows will be able to download required root certs on the fly.

    See:
    Certificate Support and the Update Root Certificates Component
    http://technet.microsoft.com/en-us/library/bb457160.aspx
    http://technet.microsoft.com/en-us/library/cc733922(WS.10).aspx

    But this does only work, if the server can access the microsoft servers directly (proxies and firewalls may prevent that). So it is a good idea to double check, that the issuing intermediate CA and rootCA is installed on all servers . The clients must trust the rootCA but thats done by KB931125 on clients)

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Friday, January 4, 2013 7:40 PM
  • The statement that:

       -the "Issued To" and "Issued by" must be the same for a CA cert in the Trusted Root Certification Authorities store for the Lync  2013 FE to start

    is incorrect in my case, and I believe incorrect in general.

    I have certs where the "Issued To" does not equal "Issued By" in the Trusted Root Certification Authorities store for the Lync  2013 FEand my Lync 2013 FE starts just fine (once I removed all the certs issued by KB931125 on my Lync FE.

    Saying that removing all certs where these two attributes are not equal will resolve the FE not starting is misleading and wrong, in my opinion.

    Friday, January 4, 2013 7:56 PM
  • Frank,

    Re above: The Update "KB931125 Update for Root Certificates For Windows XP [December 2012]" was updated. It was a "WSUS/Windows Update" error. This updates should only be appied on Windows Clients but not servers.

    So, then it wasn't my irresponsibility? Whhhewwww! ;-)

    Thank you.

    Stu

    Friday, January 4, 2013 8:17 PM
  • KB article related to this problem has been just published:

    http://support.microsoft.com/kb/2795828 - Lync Server 2013 Front-End service cannot start in Windows Server 2012

    Ensure also that KB931125 was not installed on server. If so just remove third party root CAs (select physical certificate stores on mmc console to view diferente stores)

    Monday, January 7, 2013 2:55 PM
  • Looks like 931125 can be cleaned up by http://support.microsoft.com/kb/2801679
    Saturday, January 12, 2013 10:47 AM
  • Thanks HomeCloset.
    Saturday, January 12, 2013 2:00 PM
  • Hi all.  I too am suffering from this problem, front end stuck on starting on windows 2012.

    I've been through the above replies with no luck, my trusted root store is clean, I've run the fixme, but I'm still seeing lots of SChannel faults in the event logs, I'm also not seeing the errors regarding the fabric and user placement.

    The server was installed on the 20th December and had been working fine until it's last reboot yesterday.

    At the moment I'm reinstalling the front end, still on 2012 but with any windows updates.

    If this fails I'm planning on adding a second front end server to the pool, but using 2008R2

    Any advice would be very much appreciated!

    Cheers

    Stephen.

    Wednesday, January 16, 2013 11:25 AM
  • The Basic things.

    1. the Root certificate store should only contain ROOT Certs (not intermediate or others)

    2. the number of the Root Certs should not exceed the SCHANNEL limits.

    3. Intermediate certificates should be in the corresponding zertificate container.

    Thats all. All my Lync 2013 Servers on Win2012 with the "Start Problem" are running now after moving certificates to the "right" store.


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Hello all.  This is the second Lync 2013 install I have done on Windows Server 2012.  The first one, I did not hit this issue, but I did today, and this thread helped me fix it.

    There seems to be a lot of confusion on "what to clean up" - so I figured I would post what I did, since it was minimal.  I saw the reg hack that "worked" - I skipped that because I don't like having a fix like that.

    The ONLY thing I did...   was deleted my Enterprise CA's cert from the "Intermediate Certification Authorities" list.  I left it in the Trusted Roots, however.  Restarted the Lync FE, and all services started OK.   Please, please get this thread marked with an answer so people don't read the whole thing and try 5 things!

    • Proposed as answer by Andrus M Thursday, March 7, 2013 7:54 PM
    Monday, February 25, 2013 6:25 PM
  • Bad news.  I am now getting this on a Windows 2008 server that is hosting Lync EE Front End as well.
    Tuesday, March 5, 2013 12:04 AM
  • Had this issue at two custommers so far with Lync 2013 and Windows Server 2008R2. Only resuloution so far was a completely new Topology. Please let us know if anyone out there fixed this issue.

    Tuesday, March 5, 2013 11:36 AM
  • As this seems to apply to "upgrades" only and reading between the lines of the above, is it fair to say that this issue only surfaces when you assign a Server 2012 edge to your 2013 pool?

    Prior to doing that, if you are following the MS instructions, your Lync 2013 on Server 2012 FE server would be talking to the existing Lync 2010 Edge on Server 2008. And I *think* from the above, whilst this is the case, the 2012 FE works fine.

    I imagine for most people, replacing the edge with the new version would be the last job you do. And maybe it is then that the problem surfaces.

    I cannot be exactly sure of the sequence of events with me, but I think the above is quite likely what happened. I cannot imagine that I would not have noticed the problem on the FE sooner otherwise.

    This is not true.  I have a server 2012 Domain with a CA.  I re-issued my certs internally and correct a few of my issues.  I had applied the certs wrong to begin with.  However, once the Edge server went up and I fixed the Cert issue there I still can't get the Lync Server front-end service to start.

    I have done the following commands

    Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery 

    Reset-CsPoolRegistrarState -PoolFqdn "atl-cs-001.litwareinc.com" -ResetType FullReset

    The service still refused to come up.  I am not getting any feed back in logs one way or the other now.


    Re-assigning my internal certificate solved my problem too. After a while the service was started and Lync was functioning.
    In my case though, server OS was Windows 2008 R2 SP1.
    • Edited by ArgiDio Tuesday, March 5, 2013 12:12 PM
    Tuesday, March 5, 2013 12:11 PM
  • Cleaning up the Trusted Root Certificates list solved the problem for me.  I have about 13 certs in the list now on my Server 2012 Standard server running Lync 2013 SE FE.

    Looks like 931125 can be cleaned up by http://support.microsoft.com/kb/2801679

    Tuesday, March 5, 2013 12:30 PM
  • Ensure you have run through http://support.microsoft.com/kb/2795828 even though it's Win 2008 R2. Sorting out the certificates into the right containers and rebooting the Lync server always works for me.
    Tuesday, March 5, 2013 3:04 PM
  • Ensure you have run through http://support.microsoft.com/kb/2795828 even though it's Win 2008 R2. Sorting out the certificates into the right containers and rebooting the Lync server always works for me.

    I have done that (as I did on my 2012 Lync servers successfully) without success  :(

    Opened a MSDN support case this morning.  I need this resolved.  113030510263513 if you are in PSS  :)

    Tuesday, March 5, 2013 4:20 PM
  • It might be something else. Any additional information in the lync Eventlog log?.  So if the process is still "starting" you should still be able to see some warnings/errors in the eventlog preventing the start.

    Th main issue of the FE startup Problem af that thread are certificates. And it is really not easy to track that down. So even i had to do that two times, because i missed one single thing at a customer.

    So please double check everything.  And yes. it can still be something else. Is is a single Server or a pool of servers ?.  especially pools may take longer to start.

    LyncFed: frank.carius@netatwork.de


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Tuesday, March 5, 2013 4:32 PM
  • Removing CA certificate from Intermediate Certification Authorities works. Thank you for making it cristal clear :).

    Thursday, March 7, 2013 7:55 PM
  • gettin this error too on my 2008r2s. certs are in correct stores.

    Is the possibillity to access/to download the CRLs a requirement for the service to start?

    Monday, March 11, 2013 2:05 PM
  • I got the same error here. New greenfield environment running Windows Server 2012 / Lync Server 2013.

    Tried the resetfunctions but the Front-End service is stuck at 'Starting'

    Any update for this?

    Tuesday, March 19, 2013 10:22 AM
  • Have you run through the Resolution in http://support.microsoft.com/kb/2795828 -- that has reliably been the solution for me (three separate occasions, one on a customer site).
    Tuesday, March 19, 2013 11:43 AM
  • Hi, yes I read that article and I have a bunch of certificates in that store but when running the script:

    Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Format-List * | Out-File "c:\computer_filtered.txt"

    ... the texfile is empty, it cannot find any certs that are misplaced...

    Tuesday, March 19, 2013 11:54 AM
  • Did you also check your intermediat certificates folder? sometimes there is a wrong certificate in there.
    If that does not work please try the registry key workaround to see if this fixes the problem. if that does the trick then undo the registry and manualy check your certificates again, and maybe do a manual update for the Microsoft certificates. good luck!
    Friday, April 5, 2013 7:47 AM
  • I came acroos the same issue on Windows Server 2008 R2 during Lync 2013 migration. I ran the powershell cmdlet Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Format-List * | Out-File "c:\computer_filtered.txt".

    In fact there are some certificates in the root cert store of the lync 2013 server machine I couldn't delete I checked the Intermediate Cert Store. There I found a duplicate of our own Root CA certificate. I've deleted this. It works for me now.

    Don't forget to check GPOs or other deployments (SCCM Packages, ...) which might deploy certificates in your organization!!! ...

    Monday, April 22, 2013 1:17 PM
  • I tried to move a wrongly-placed certificate to correct folder, but that did not help.

    Resolution (for me) - Install CU1 for Lync 2013 (http://support.microsoft.com/kb/2809243) and update database as described in KB.

    Regards,


    Alex Ignatenko | MCSE | MCITP | MCTS:SCCM, Lync, Virtualization

    • Proposed as answer by Alenat Monday, April 22, 2013 11:14 PM
    Monday, April 22, 2013 11:14 PM
  •    

    Resolution (for me) - Install CU1 for Lync 2013 (http://support.microsoft.com/kb/2809243) and update database as described in KB.

    Thanks for the tip.  I had this same exact problem.  I have a 2010 environment that I'm upgrading to 2013.  I created the 2013 pool and published the topology.  The new databases didn't create and this was preventing the Front End from starting.

    I manually created the databases using the topology builder, but the services still wouldn't start.  However, after applying the update, the services started right up.

    Friday, June 21, 2013 7:52 PM
  • Is this still a problem with 2012? I'm currently seeing the same logs and no users can login. I am using Server 2012 for all my Lync servers.
    Wednesday, July 10, 2013 3:37 AM
  • Is this still a problem with 2012? I'm currently seeing the same logs and no users can login. I am using Server 2012 for all my Lync servers.

    If you're running 2012 and your Front End Services aren't starting, it could be a few different things that are documented in this thread.  I would start be updating to CU1 (this fixed it for me on a fresh install using 2012 and lync 2013).  The installer is located at http://support.microsoft.com/kb/2809243 .  If that doesn't do it, then you may have some Certificates improperly installed.  There should be more about that higher up in this thread.

    Wednesday, July 10, 2013 12:15 PM
  • My front end services start but get a 301 redirect problem when checking it. It is like it keeps redirecting and times out. I am also running Lync Hosting Pack v2 and not the regular Lync.

    I had it working until I ran the LyncUpdateInstaller that was included with the hosting pack so I'm thinking something with the updates messed it up.

    I checked all the certificates and there are no certificates in the wrong place. I opened another forum about my problem: http://social.technet.microsoft.com/Forums/lync/en-US/383de1d8-ac2a-4edd-9429-6b6b8c0cefcb/error-message-redirect-attempts-exceeded-maximum-allowed-limit-of-3-redirects#f9dba001-1bb8-46d6-bdad-c20643f5db29

    I'm going to open a case with Microsoft now

    Wednesday, July 10, 2013 1:52 PM
  • I had this same problem, and nothing in this thread worked for me. However I downloaded the LyncUpdateInstaller.exe from Lync 2013 and applied all updates, rebooted the server, and the service started after about 2-3 minutes.

    http://www.microsoft.com/en-us/download/details.aspx?id=11551

    Tuesday, July 16, 2013 7:42 PM
  • Running the tool you basically installed Cumulative Updates as it is recommended above.  :)


    Alex Ignatenko | MCSE | MCITP | MCTS:SCCM, Lync, Virtualization

    Tuesday, July 16, 2013 7:51 PM
  • Vinsanity904 link is for Lync 2010
    Thursday, July 18, 2013 2:45 PM
  • Set the service that does not start to disable.

    Restart the server and when all other services are started set back the service to delayed start. but dont start it.

    Then run Reset-CsPoolRegistrarState -PoolFQDN <PoolFQDN> -ResetType ServiceReset

    The service should now start and after this it should also be able to reboot as usual.

    I got the error on FE with win2k8r2sp1. I tyried these steps it works. the fe service can start. you need wait for nearly 15 mins after you run the cmd.

    Tuesday, August 13, 2013 8:15 AM
  • Windows 2012 Environnement ?

    IF yes : Check your certificat root container

    Only root certificat should be in the root container  !

    laurent Teruin


    lteruin@hotmail.com http://unifiedit.wordpress.com/

    Tuesday, August 13, 2013 9:30 AM
  • Make sure the URL(s) for your Edge services (access,web conferencing, and AV) does not match the name of your Front End server. For example, If you have the following Edge URLs:

    Access: lync.domain.com

    Web Conferencing: webconf.domain.com

    AV: av.domain.com

    Then make sure your Front End server name is not lync.domain.com or any of the other two. I noticed that when I added my Edge server I ran into the problem of my Front End service not starting and getting the routing group error in the event log like everyone else here. I reviewed my Edge URLs and realized one shared a name with my Front End server. I change the Edge URL name and now everything works fine. I hope this helps you.

    Monday, August 19, 2013 4:26 PM
  • I'm having the same problem. I checked the certificate store on all my server and they are fine. Two of my three front end servers went down and I can't get it back up. Seems Lync 2013 isn't really enterprise ready because you would think if even one server is running it should work. What are the exact steps to do a service reset? I stopped all services on all my front end servers and ran the command. Still it is stuck starting. I am running the hosting pack. Is there a good way to just downgrade my lync to 2008 r2? Everything I read seems that these issues do not happen on 2008 r2 and only happen on 2012
    Sunday, August 25, 2013 12:47 AM
  • It Looks like there is some principal Problem in your infrastructure (and maybe understanding how lync 2013 works)

    First: the "Certificate Problem" is solvable on Win2012. The Problem is not there in Win2008R2 but such a small Thing should not change your decision about the base os.

    Lync 2013 Frontend Servers in the same pool are a Kind of Cluster. Not a "MS Cluster" but ain Windows fabric Cluster. They replicate data between the Servers and a single or even two failed Servers are not a Problem as Long as a majority is still alive. Dont shutdown 3 or more at the same time. This will be an outage for some users. (a user i homed on up to three Servers but no more) 

    So thats the reason why you should not build a Cluster with 6 FEs and put 3 FEs in one datacenter and 3 FEs in the other. DataCenter Failover is more a "Backup Pool"-Topic.

    And if you run 3 Servers and two are down, then the remaining Server is "alone" and not the majority. Here we are. If you have only two FEs, then the SQL db is some Kind of "majority".

    So don't shut down two of three Servers.


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Sunday, August 25, 2013 6:02 PM
  • Hi

    All of the solutions didnn't worked for me

    Finally I found that the customer has disabled IPv6 on the Ethernet interface

    I Just enabled the IPv6 protocol and all works fine.

    Itzik

    Please help us to find unanswered Questions by tagging answers as answer

    Sunday, September 15, 2013 1:25 PM
  • for me, it was due to several issues!

    Restarting SQL Servers might solve your problem.

    I think also the order of starting the Lync front end servers may affect the services and cause them to not start properly if for example you started Lync FE 2 while Lync FE 1 in pool 1 is not started yet or in the process of restarting.

    So starting Lync FE 1 first before Lync FE 2 and Lync FE 3 will not get the services to get delayed while starting and crash.

    hope this helps.


    Mohammed JH

    Wednesday, October 2, 2013 2:27 PM
  • Hi i have a similar case, the Fe service wont start and i get a shannel error

    "The certificate received from the remote client application has not validated correctly. The error code is 0x80090349. The attached data contains the client certificate."

    and after i enabled capi2 logging i got 

    "Result The certificate's CN name does not match the passed value. 

    [ value]  800B010F "

    I have tried recreating the certifates through the wizzard and also manually 

    2x Fresh 2012 server ,new domain, and setting up the hosting lync in a enterprise pool

    Regards Omar


    Thursday, October 3, 2013 8:53 AM
  • Try enabling CAPI2 debug logging on the server, restart the service and look for errors in the CAPI2 log.

    If you have a certificate issue it should be logged there.

    See http://blogs.technet.com/b/instan/archive/2011/09/09/using-wevtutil-to-capture-and-view-capi2-operational-logging.aspx for how to enable CAPI2 logging.

    Thursday, October 3, 2013 8:54 AM
  • So I have an environment that's been running fine for months with 2010 and 2013 in the same domain, and now neither of the 2013 FEs will start.  Event log shows:

    Server startup is being delayed because fabric pool manager has not finished initial placement of users.

    Currently waiting for routing group: {76EFF9AE-3788-5DF9-A2A5-333C5BB5F95B}.

    Number of groups potentially not yet placed: 3.

    Total number of groups: 4.

    Cause: This is normal during cold-start of a Pool and during server startup.

    If you continue to see this message many times, it indicates that insufficient number of Front-Ends are available in the Pool.

    Resolution:

    During a cold-start of a large Pool it can take upto an hour for the placement process to finish as it needs to populate all the Front-End databases with data from the Backup Store. If the Pool is running and the Front-End is just started, this is normal for some time. If this repeats for a long time, ensure that all the Front-Ends configured for this Pool are up and running. If multiple Front-Ends have been recently decommissioned, run Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery to enable the Pool to recover from Quorum Loss and make progress.

    I've tried all of the certificate fixes listed here, changing the SCHANNEL registry key, running Reset-CsPoolRegistrarState with both QuorumLossRecovery and FullReset, patching all lync 2013 servers to the latest CU, and multiple reboots of all Lync and SQL servers.  Still no luck-Front End service is stuck in "Starting".  Is there anything else that I should be trying here?  I have 2 2013 EE FEs on Server 2012 Datacenter, as well as a separate 2010 EE FE conferencing pool on 2008 R2. 


    Tuesday, October 15, 2013 6:39 PM
  • OK, I think I managed to get it working (finally).  The trick was running Get-CsPoolFabricState, which reported that one of the services (fabric:/lync/Routing/GUID or something like that-I don't have the output anymore) had no primaries.  Resetting the pool registration state didn't have any effect, and I couldn't find a reference to the GUID anywhere (orphaned routing rule maybe)?  Then I ended up running install-csdatabases with the -clean flag, and then get-cspoolfabricstate returned the correct data, and the front end service went to Started. 

    Anyone have any idea what the extra entry could have been there, or why it wasn't owned by either of the Front End servers in the pool? 

    • Proposed as answer by Chris Bardon Tuesday, October 15, 2013 7:49 PM
    Tuesday, October 15, 2013 7:48 PM
  • i have encountered the same issues when migration from lync 2010 to 2013 on windows server 2012 R2, for sometime i have searching and find out solution is below

    Add the REG_DWORD “SendTrustedIssuerList” to the SCHANNEL registry location. The value is going to be 2:

    HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

    after restrting the server, the service is now running. 

    Strange thing is this is not documented on microsoft documents

    Regards,

    raymond.


    Raymond

    Monday, August 18, 2014 5:57 PM