locked
Cant Sign in Server temporary unavailable RRS feed

  • Question

  • Hello Experts,

    I'm facing the subjected error with 2 different types of client systems on different locations while SFB on other systems on the very same location is working fine. Whenever I'm trying to login on SFB on any of these 2 systems with different OS, I'm getting the error "Cant sign in. The server is temporary unavailable" after 5 mins of waiting.

    Although on same site, SFB on all other systems is working fine which proves its not a server issue.

    These are the OS of client on which I'm facing error

    a) Windows 7 - 32 bit on site A (All SFB on other systems on same site A is working)

    b) Windows 8.1 - 64 bit on site B (All SFB on other systems on same site B is working)

    So far what I found out online is mentioned below along with its status when I did so.

    1. Completely uninstall and install SFB. (DIDNT WORKED)
    2. Microsoft Online Services Sign-In Assistant. (DIDNT WORKED)
    3. Delete Sign in info. (DIDNT WORKED)
    4. Temporary disable anti-virus or firewall.(DIDNT WORKED)
    5. Bypass proxy. (DIDNT WORKED)
    6. Delete all SFB profiles and then delete HKCU\Software\Microsoft\MSOIdentityCRL  (Such registry Doesn't exist)
    7. Kill lync.exe process and now create a local user account on computer (lusrmgr.msc)

    Add this to Admin security group, now navigate where lync.exe is

    While holding shift key down, right click on lync.exe and run as diff user

    Login with credentials you just created.

    Lync will open and launch the new user configuration window

    Sign in to lync with your username and password. (DIDNT WORKED)

    I did studied logs on Snooper in which on

    i) Windows 7- 32 bit -->

    After the NEGOTIATE SIP request with front end, Error came when DATA RECEIVED, I/O is "IN"

    HTTP/1.1 400 Bad Request
    <hr><p>HTTP Error 400. The request is badly formed.</p>

    ii) Windows 8.1 - 64 bit

    In this no message is highlighted as error (Red highlighted)

    1st message is of NEGOTIATE SIP

    2nd message is of 200 OK

    and last message is of REGISTER SIP and nothing else afterwards.

    Hope anyone can help me to resolve this issue without suggesting me to format system.



    Tuesday, November 1, 2016 9:21 AM

All replies

  • Hi Anon.Archer,

    Welcome to post in our forum.

    Would you please tell us did you mean that the issue appeared on the specific computer in your environment ?

    Did you try to login this user on another normal computer?

    For your issue, yes, I am agree with you, it is something wrong with your SFB client side.

    In addition to your troubleshooting steps, please try to perform a clean boot on your affected computer.

    https://support.microsoft.com/en-us/kb/929135

    And try to repair office and install the latest update for SFB client, for your windows system, install the latest update on it.

    Hope this reply helpful to you.


    Alice Wang
    TechNet Community Support


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, November 2, 2016 2:45 AM
  • Hi Alice,

    I will answer all your questions in the sequence they were asked.

    1. Yes, its on only 2 systems in all locations across country.

    2. Yes, I tried login in the very same user from other system present on the very same location and it was working.

    3. Yes, I forgot to mention but yes I did tried clean boot on the affected computers but that too in vain.

    4. Already tried repairing Office and installing all updates related to SFB. Issue is still there.

    Windows is up to date on both systems.

    Wednesday, November 2, 2016 6:26 AM
  • Sorry,

    Just need to know whether anyone has an update regarding this?
    Thursday, November 3, 2016 8:31 AM
  • Hi Anon.Archer,

    Thanks for your response.

    Would you please tell us did the affected computers join the domain?

    If not, the non-domain joined computer need to trust your Root CA.

    To do this on a WORKGROUP computer do the following.

    1.Go to https://<yourca.fqdn>/CertSrv

    2.Click on Download a CA certificate, certificate chain, or CRL

    3.Select Base 64 and Click on Download CA certificate.

    4.Save this somewhere on the computer in the workgroup.

    5.Next open up the MMC and Add the certificates plugin making sure to select Computer Account then Local computer.

    6.Browse to Trusted Root Certification Authorities/Certificates and import the certificate you saved

    Moreover, make sure the affected computer in the same subset with the normal computers.


    Regards,

    Alice Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, November 8, 2016 9:36 AM
  • Dear Alice,

    All systems are already joined in DOMAIN.

    Tuesday, November 8, 2016 9:58 AM
  • One more update to this issue.

    I'm facing this issue now in 10 systems and count is increasing.

    Out of these 10, I found a specific error in 3 systems in Snooper.

    HTTP/1.1 400 Bad Request
    Content-Type: text/html; charset=us-ascii
    Date: Wed, 09 Nov 2016 08:32:48 GMT
    Connection: close
    Content-Length: 311
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
    <HTML><HEAD><TITLE>Bad Request</TITLE>
    <META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
    <BODY><h2>Bad Request</h2>
    <hr><p>HTTP Error 400. The request is badly formed.</p>
    </BODY></HTML>

    Can any one explain me what this is about.

    Wednesday, November 9, 2016 10:26 AM
  • Hi Anon,

    When troubleshooting an HTTP 400 condition, it is important to remember that the underlying problem is that the client has sent a request to IIS that breaks one or more rules that HTTP.sys is enforcing.  With that in mind, you will want to see exactly what the client is sending to IIS; to do this, capture a network trace of the client sending the bad request.  You can analyze the trace to see the raw data that the client sends to IIS, and to see the raw response data that IIS sends back to the client.  You can also use an HTTP sniffer tool called Fiddler; this is a great tool as it allows you to see the HTTP headers even if the client and server are communicating over SSL.

    Please refer to

    https://blogs.msdn.microsoft.com/webtopics/2009/01/29/how-to-troubleshoot-http-400-errors/


    Regards,

    Alice Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, November 14, 2016 1:53 AM