مشکل در اتصال اتوماتیک کلاینت های lync 2013 بعد از به روز رسانی از 2010 به 2013

سلام دوستان
من در یک شبکه lync server 2010 را به نسخه ی جدید تر یعنی lync server 2013 ارتقا دادم . خب اغلب کلاینت ها از قبل نسخه ی 2013 بودند و با به روز رسانی سرور به 2013 نیاز به تغییر خاصی نداشتند .
اکثر کلاینت ها به راحتی و بدون هیچ مشکلی به کار ادامه دادند اما روی بعضی از کلاینت ها و بعضی از سیستم هایی که ویندوز عوض کرده بودند ی مشکل ایجاد شده است.
lync 2013 نمی تواند به صورت اتوماتیک به سرور لاگین شود . اما اگر از حالت اتوماتیک خارج و به صورت دستی آدرس FE را بدهم کلاینت لاگین می شود .
روی همان کامپیوتری که lync 2013 نمی تواند اتوماتیک لاگین شود با همان یوزر lync 2010 نصب کردم . برایم تعجب برانگیز بود که روی همان سیستم و با همان نام کاربری lync 2010 بدون هیچ مشکلی اتوماتیک لاگین شد .
چه فرقی میتونه بین 2010 و 2013 باشه ؟؟
این رو اضافه کنم که تمام رکورد های DNS مربوط به Lync ساخته شده و ارتباط هم برقرار است .
لینک سوال در technet
[url]https://social.technet.microsoft.com/Forums/office/en-US/b5b747e8-cea7-479f-97d7-f0c4b3d9b2ca/some-of-lync-client-2013-can-not-sign-in-automatically-after-upgrade-lync-server-2010-to-2013-but?forum=lyncdeploy[/url]

سلام
پاسخ برای مشکل فوق :
در اصل این مشکل زمانی به وجود می آید که شما از Office communicator 2007 R2 یا Lync Server 2010 به Lync Server 2013 به روز رسانی انجام دهید . خب خیلی تلاش کردم و تست های زیادی انجام دادم اما هر چه بیشتر تلاش میکردم به نتیجه ای نمی رسیدم . نکته ی تعجب آور برای من این بود که چطور lync client 2010 به خوبی کار میکند ولی lync 2013 مشکل دارد .
ابتدا روی کلاینت لینک، لاگ را فعال کردم لاگ زیر مشاهده شد :
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server lynct$. The target name used was HTTP/alynct.hanyco.net. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMAIN.NET) is different from the client domain (DOMAIN.NET), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

خب لاگ رو سرچ کردم به صفحه ی زیر رسیدم :
[URL]http://www.hayesjupe.com/lync-2013-client-unable-to-sign-in-kerberos-error/#comments[/URL]
خب حالا محتوایات صفحه به شرح زیر بود :
I upgraded my servers to Lync 2013 a few months back and all has been working fine….. but in the past few days, i upgraded a couple of home machines with fresh installs – everything was working ok apart from Lync 2013 client, which came up with access denied errors. (but if signed in on an existing install, everything was still fine)
After some investigation, i found the following event in the System Event Log (event ID 4)
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server im04$. The target name used was HTTP/im04.company.com.au. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (company.COM.AU) is different from the client domain (company.COM.AU), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
fair enough…. next thing setspn -q http/im04.company.com.au, which returned the account LyncKerbAuth… a computer account created by the lync install process.
“thats correct” i thought…. but after some short searching, found the test PS commandlet of “[I]Test-CSKerberosAccountAssignment -Identity <sitename> -Report “C:TempLog.htm” -Verbose[/I]” which failed with lots of red!
Test-CSKerberosAccountAssignment : The Kerberos configuration on im04.company.com.au is invalid. The expected assigned account is companylynckerbauth. Ensure that the account has not expired, and the
configured password on the machine matches the Active Directory password of the account.
After some short searching, the process to reset the account is

[LIST=1][*]Set-CsKerberosAccountAssignment -UserAccount “CompanyLycKerbAuth” -Identity “site:<sitename>” (this step sets Lync to use that account)[*]Enable-CsTopology (this step activates the above change)[*]Set-CsKerberosAccountPassword -UserAccount CompanyLyncKerbAuth (this step sorts out the passwords)[/LIST]
Then i ran [I]Test-CSKerberosAccountAssignment -Identity <sitename> -Report “C:TempLog.htm” -Verbose[/I] again, and got muchy less red – and all clients can now logon.
Not sure how it broke – maybe something in the 2010 to 2013 migration process that i missed – but it is/was a little odd that it didnt show up for existing clients and seemed to lay dormant for a few months – or it coulld have been something to do with Lync 2013 CU1.
Anyhoo – hope that helps someone else that might into the same issue.
خب متوجه شدم که در هنگام نصب لینک 2010 در قبل دو اکانت به نام sitkeruch ایجاد شده است برای هر سایت یکی .
وقتی دستور زیر رو روی کلاینت می زدم


C:\Windows\system32>setspn -q http/lync.domain.net
Checking domain DC=domain,DC=net
CN=Siteuckerb,OU=OFF Clients,OU=Computer Accounts,DC=Domain,DC=net
http/lync.domain.net

Existing SPN found!

مشاهده می شود که این دستور به همان کانتی که برای احراز هویت از نوع Kerberos استفاده می شود ، اشاره دارد.
عجله کردم . اکانت ها رو حذف کردم که خب نباید به این سرعت حذف میکردم شاید !!!
اما دقیقا همون لحظه لینک وصل شد و مشکل اعتبار سنجی حل شد .
عالی
به بقیه ی داستان دیگه فکر نکردم !!!!
خب بقیه ی داستان شروع شد :
توپولوژی نمی تواند Enable شود . دقیقا دنبال همین اکانت ها میگردد.
جستجو کردم . این دو اکانت را از توپولوژی هم حذف کردم .جواب ساده است .دستور زیر را اجرا کردم در پاورشل:
Remove-CsKerberosAccountAssignment -Identity "site:SiteName"

Enable-CsTopology
جواب را در technet ببینید :
[URL]https://technet.microsoft.com/en-us/library/gg398749.aspx[/URL]
توضیح بیشتر که این اکانت چیست ؟
[url=http://blogs.technet.com/b/jenstr/archive/2010/09/23/kerberos-and-microsoft-lync-server-2010-web-services.aspx]Kerberos and Microsoft Lync Server 2010 Web Services - Jens Trier Rasmussen - Site Home - TechNet Blogs[/url]
صفحه ی اصلی در technet مایکروسافت :
[URL]https://technet.microsoft.com/en-us/library/gg398976.aspx[/URL]
گویا در لینک 2010 و نسخه های قبلی برای احراز هویت کاربران و ارتباط با سرویس ها از این اکانت استفاده میشده است که در لینک 2013 این ویژگی حذف شده است .
امیدوارم که بعد ها برای دوستانی که این مشکل را خواهند داشت مفید باشد .البته اگر دوستان اطلاعات کامل تری دارند خوشحال میشوم که توضیح بیشتری دهند .

[COLOR="silver"][SIZE=1]- - - ادامه - - -[/SIZE][/COLOR]

سلام
پاسخ برای مشکل فوق :
در اصل این مشکل زمانی به وجود می آید که شما از Office communicator 2007 R2 یا Lync Server 2010 به Lync Server 2013 به روز رسانی انجام دهید . خب خیلی تلاش کردم و تست های زیادی انجام دادم اما هر چه بیشتر تلاش میکردم به نتیجه ای نمی رسیدم . نکته ی تعجب آور برای من این بود که چطور lync client 2010 به خوبی کار میکند ولی lync 2013 مشکل دارد .
ابتدا روی کلاینت لینک، لاگ را فعال کردم لاگ زیر مشاهده شد :
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server lynct$. The target name used was HTTP/alynct.hanyco.net. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMAIN.NET) is different from the client domain (DOMAIN.NET), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

خب لاگ رو سرچ کردم به صفحه ی زیر رسیدم :
[URL]http://www.hayesjupe.com/lync-2013-client-unable-to-sign-in-kerberos-error/#comments[/URL]
خب حالا محتوایات صفحه به شرح زیر بود :
I upgraded my servers to Lync 2013 a few months back and all has been working fine….. but in the past few days, i upgraded a couple of home machines with fresh installs – everything was working ok apart from Lync 2013 client, which came up with access denied errors. (but if signed in on an existing install, everything was still fine)
After some investigation, i found the following event in the System Event Log (event ID 4)
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server im04$. The target name used was HTTP/im04.company.com.au. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (company.COM.AU) is different from the client domain (company.COM.AU), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
fair enough…. next thing setspn -q http/im04.company.com.au, which returned the account LyncKerbAuth… a computer account created by the lync install process.
“thats correct” i thought…. but after some short searching, found the test PS commandlet of “[I]Test-CSKerberosAccountAssignment -Identity <sitename> -Report “C:TempLog.htm” -Verbose[/I]” which failed with lots of red!
Test-CSKerberosAccountAssignment : The Kerberos configuration on im04.company.com.au is invalid. The expected assigned account is companylynckerbauth. Ensure that the account has not expired, and the
configured password on the machine matches the Active Directory password of the account.
After some short searching, the process to reset the account is

[LIST=1][*]Set-CsKerberosAccountAssignment -UserAccount “CompanyLycKerbAuth” -Identity “site:<sitename>” (this step sets Lync to use that account)[*]Enable-CsTopology (this step activates the above change)[*]Set-CsKerberosAccountPassword -UserAccount CompanyLyncKerbAuth (this step sorts out the passwords)[/LIST]
Then i ran [I]Test-CSKerberosAccountAssignment -Identity <sitename> -Report “C:TempLog.htm” -Verbose[/I] again, and got muchy less red – and all clients can now logon.
Not sure how it broke – maybe something in the 2010 to 2013 migration process that i missed – but it is/was a little odd that it didnt show up for existing clients and seemed to lay dormant for a few months – or it coulld have been something to do with Lync 2013 CU1.
Anyhoo – hope that helps someone else that might into the same issue.
خب متوجه شدم که در هنگام نصب لینک 2010 در قبل دو اکانت به نام sitkeruch ایجاد شده است برای هر سایت یکی .
وقتی دستور زیر رو روی کلاینت می زدم


C:\Windows\system32>setspn -q http/lync.domain.net
Checking domain DC=domain,DC=net
CN=Siteuckerb,OU=OFF Clients,OU=Computer Accounts,DC=Domain,DC=net
http/lync.domain.net

Existing SPN found!

مشاهده می شود که این دستور به همان کانتی که برای احراز هویت از نوع Kerberos استفاده می شود ، اشاره دارد.
عجله کردم . اکانت ها رو حذف کردم که خب نباید به این سرعت حذف میکردم شاید !!!
اما دقیقا همون لحظه لینک وصل شد و مشکل اعتبار سنجی حل شد .
عالی
به بقیه ی داستان دیگه فکر نکردم !!!!
خب بقیه ی داستان شروع شد :
توپولوژی نمی تواند Enable شود . دقیقا دنبال همین اکانت ها میگردد.
جستجو کردم . این دو اکانت را از توپولوژی هم حذف کردم .جواب ساده است .دستور زیر را اجرا کردم در پاورشل:
Remove-CsKerberosAccountAssignment -Identity "site:SiteName"

Enable-CsTopology
جواب را در technet ببینید :
[URL]https://technet.microsoft.com/en-us/library/gg398749.aspx[/URL]
توضیح بیشتر که این اکانت چیست ؟
[URL]http://blogs.technet.com/b/jenstr/archive/2010/09/23/kerberos-and-microsoft-lync-server-2010-web-services.aspx[/URL]
صفحه ی اصلی در technet مایکروسافت :
[URL]https://technet.microsoft.com/en-us/library/gg398976.aspx[/URL]
گویا در لینک 2010 و نسخه های قبلی برای احراز هویت کاربران و ارتباط با سرویس ها از این اکانت استفاده میشده است که در لینک 2013 این ویژگی حذف شده است .
امیدوارم که بعد ها برای دوستانی که این مشکل را خواهند داشت مفید باشد .البته اگر دوستان اطلاعات کامل تری دارند خوشحال میشوم که توضیح بیشتری دهند .

دوست گرامی درود
سرورهای ما 2010 بودند الان داریم اونهارو به 2012 ارتقا میدیم. lync 2013 رو راه اندازی کردیم تمام مراحل به خوبی و دستی پیش رفته اما الان کلاینتهای lync سرور رو پیدا نمی کنند. دستی یا اتوماتیک، lync cclient 2010 یا lync client 2013 فرقی نمیکنه. ca server هم درست کار میکنه. فقط موردی که هست certificate ها توسط dc داده میشه.آیا این مورد درسته یا اینکه certificate رو domain باید بده؟
ممنون میشم راهنمایی بفرمایید

سلام دوست عزیز . سوالتون اشتباه هست . در مورد وصل نشدن اتوماتیک چک کنید که رکورد های DNS را درست تعریف کرده باشید . همچنین ببینید قابل دسترسی هستند یا نه .
Certificate ها باید توسط CA قاعدتا صادر شوند که چون محیط شما دامین است احتمالا رل مربوط به CA Server روی یکی از DC ها راه اندازی شده است .
در پروسه ی نصب lync خود Ca Server را شناسایی میکند .