locked
registrar pool (sfb 2015 std) vs front-end pool (lync 2013) - client access RRS feed

  • Question

  • Trying to upgrade and simplify: from lync 2k13 enterprise (2 enterprise fe servers, 1 be, 1 edge, 1 tmg- in two sites) to sfb std (1 fe, 1 edge, F5 for reverse proxy). Am 1/2 way through build- coexisting.

    my sfb account has been moved to one of my sfb servers as its registrar; however, when I look, my client is still connecting to old f/e pool.

    --I KNOW-- 2 fe servers not supported. Ug. I plead the 5th- I plead that I inherited it. 1K users only. the 2 sfb servers are pool paired.

    what am I missing- dns entry lacking? Even when I manually enter the new sfb servers, it flips back to the 2k13 fe pool.

    Thursday, May 12, 2016 9:11 PM

Answers

  • I would not check at first on the group policies.

    Normally group policies can be implemented to change the client default behaviour (Ex: skype to Lync UI). But the default client behaviour here to update registrar pool in the registry. Hence, my understanding would be it might not updated as client automatically store it.

    ServerAddressExternal REG_SZ <user value> Personal The external server URL
    ServerAddressInternal REG_SZ <user value> Personal The internal server URL

    just referred the below link to check the lync registries auto update.

    http://memphistech.net/skyperegistry.html

    But, if you still suspect group policies, you can exclude that particular machine from GPO and check.

    You might need to ask GPO admins to check the computer's security groups. 


    - Muralidharan. Please mark as answer/useful if my contribution helps you.


    Friday, May 13, 2016 6:49 PM

All replies

  • When you run the command Get-CsUserPoolInfo, please check whether it shows old or new pool.

    I dont think DNS will be a problem. The client always try to reach the registrar server, even you manually connect with other servers.

    How many users are in SFB pool. Did all users having the same issue?

    While moving users, did you check the force option?


    - Muralidharan. Please mark as answer/useful if my contribution helps you.


    Friday, May 13, 2016 9:14 AM
  • Good starting point.

    The Get-CSUsersPoolInfo for my identity (originally existed in the enterprise front end pool) shows proper registration to ONLY the new sfbpool. There are about a dozen users in the new pool at most. All of them, save maybe one, were originally created in the pool. I do not recall using the /force option for my account, but I don't trust my memory completely. Thinking now that I haven't verified with the other accounts- if they cling to the old pool. Thinking the old pool might be a display thing-- I did do a test of failover by powering off the server on which I was registered. It did stop my access for 5-7 min before my access was good again. That is the sfb std pool pairing worked great.

    --tested with an account that never existed on the old server pool- works like butter! Great.

    ---re-tried the move: moved my account back to old pool, then back again, each time using -force. The move worked fine and fast but no improvement.

    • Edited by dkemper314 Friday, May 13, 2016 3:15 PM
    Friday, May 13, 2016 1:23 PM
  • Think there's a policy somewhere in play. New notes.

    1. I saw that I'd *duh* left manual sign in to old pool for my last test. Or did I...

    2. I changed manual sign in pool from *oldpool* to *newpool*. In the past when I'd changed this and signed in it reverted. This time, I closed it, but thought I'd mistyped and opened it immediately without signing out of Lync etc. And it had already reverted. Also tried blanking it out and going to automatic. Still stuck to *old pool*

    3. Not well defined observation- contacts all seemed to disappear (though I could search out anyone fine), but at some point in my going back and forth all populated again.

    Friday, May 13, 2016 3:19 PM
  • If you did force move, then your contacts will be lost.

    Hence, move option using force is not a suggested option. I just wanted to make sure if you moved with force, that might affect the account to lost the registrar info..

    As you mentioned, you created an old account in SFB pool and it worked.

    Can you create an account in enterprise pool and move to SFB pool using the command move-csuser, then check whether it still connect with old pool..


    - Muralidharan. Please mark as answer/useful if my contribution helps you.

    Friday, May 13, 2016 3:55 PM
  • No worries about the contacts. Threw me a little when they came back in the way they did. Still early enough not to stress. But need to be prepared for what's gonna happen when I do 500 people.

    Back to the main: Thanks for working with me on this. The account that I'm working with was created on the Enterprise pool and it was moved with command line (happens to be an admin account).

    And it shows up- from the client end view- as the "Server Address Internal" (and [External]) as being the Enterprise pool. Most everything else shows up as the SFB STD pool. (e.g. ABS Server or DG Server).

    I'd like to see what happens when I power down the Enterprise pool, but obviously can't during business hours (and there being two servers in it, it's a real pain to work with, so I really don't want to do it yet-- though eventually I'll have to check it as part of the decommission process.)

    Friday, May 13, 2016 5:42 PM
  • UPDATE: Found a registry key, HKCU\Software\Policies\Microsoft\office\15.0\lync

    with REG_SZ value of lyncpool01.blahblahblah for external and .blahblah for internal -I changed it to sfbstd and the client behaves as desired; however, a reg key change for all users isn't really a great option. I wonder if this might be getting set with office/group policy and not a specific lync policy. Or perhaps if only admin users would experience this.

    Friday, May 13, 2016 6:06 PM
  • I would not check at first on the group policies.

    Normally group policies can be implemented to change the client default behaviour (Ex: skype to Lync UI). But the default client behaviour here to update registrar pool in the registry. Hence, my understanding would be it might not updated as client automatically store it.

    ServerAddressExternal REG_SZ <user value> Personal The external server URL
    ServerAddressInternal REG_SZ <user value> Personal The internal server URL

    just referred the below link to check the lync registries auto update.

    http://memphistech.net/skyperegistry.html

    But, if you still suspect group policies, you can exclude that particular machine from GPO and check.

    You might need to ask GPO admins to check the computer's security groups. 


    - Muralidharan. Please mark as answer/useful if my contribution helps you.


    Friday, May 13, 2016 6:49 PM
  • Just wondering, what was the fix.

    Can you please update, whether the issue resolved and any of the fix worked..


    - Muralidharan. Please mark as answer/useful if my contribution helps you.

    Tuesday, May 17, 2016 10:43 AM
  • Not fixed. The registry keys appear to have been a temporary fix. Sometime between the last post and now, everything has reverted. My Skype for business client, which was moved to a sfb std server still shows up in the server address internal / external as the old lync 2013 f/e pool.

    it's a policy somewhere..

    Wednesday, May 18, 2016 9:13 PM
  • Solved.

    Actually not a policy at all. "Server Address Internal" and "Server Address External" as I was seeing from "Configuration Information" when ctrl + right click on the system tray icon refers to manual settings. Took a long time before I stumbled on that definition. I stumbled on it thinking that in policy there would be specific mentions of those terms and using them in a search let me to look for better definition so I might learn where they were being set. Which I did learn.

    I did not have the servers manually set at the time of all this research, but I had set them in the past, and the grayed out values stayed. I had to change a registry setting to allow me to change the values in my client and blank out the grayed out info. HKCU\Software\Policies\Microsoft\office\15.0\lync

    first I set "configurationmode" value to 2. seems like 0 locks it down, 1 makes it manually editable, but manual- or something like that. Then for good measure, I set the serveraddresexternal and serveraddressinternal values to my new sfb server. but I opened my client and blanked out the values and set the client to get the server automatically and all is good.

    Solved.

    Thursday, May 19, 2016 3:49 PM