Can this setting be changed with set-csmeetingconfiguration?  Yes and no.  You cannot change the options for "My dedicated meeting space".  You can force having only the meeting originator as presenter if you change the assignedconferencetypebydefault to "false" and then change the deignateaspresenter property to "none".  This will make all meeting the secure\private type and use a different meeting ID for all conferences.  This may not be suitable for some environments.

The other option is to educate users to click "Meeting options" in Outlook when creating the Lync meeting.  They can then select the presenter options that fit's the situation.  This option does create a one off meeting ID as well, the difference is that the user only selects this type when needed. 

This will populate the sign in with the SIP address from AD the next time Lync is started. 

For a good call it looked like this:

I initially started down this route to see what the signal levels were, not the devices listed.  What we discovered is that when this user brings his laptop out of a sleep state, sometimes his headset is not identified.  What was actually happening was he was using his laptops built-in mic and speakers during the problem calls.  Switching out the headset did not solve the issue.  I recommended he reimage his laptop to see if that resolves it.  Until that's  addressed, he must verify that the correct audio device is selected in the Lync client when he brings the laptop out of suspend.

The moral of the story is that sometimes users don't realize their equipment is not working...so make sure to check it first. 

$feservers=get-cspool "fepoolfqdn"

foreach ($server in $feservers.computers){Get-Counter -computername $server -counter "\ls:usrv - endpointcache\usrv - Active Registered Endpoints", "\ls:usrv - endpoint cache\usrv - active registered users", "\LS:SIP - Networking\SIP - Unique users connected directly"}

On the edge servers you may have to check each server separately due to firewall restrictions.  Use the following to do so:

Get-Counter  -counter "\LS:SIP - Networking\SIP - Unique users connected directly"

I recently had a case were calls from the Lync client to IP phones registered to Lync began failing.  Calls from the phone to a Lync client, or phone to phone, never fail.  This was odd because it had been working fine for months.  Upon inspection of the client logs we saw the reason "52001;reason="Client side general processing error."".  This  is an ambiguous error and upon reviewing the rest of the SIP trace, it may not be clear as to what the cause is.

I found that the phones candidate list contained 2 edge IP addresses as part of the same pair.  This caused the client to error out and cancel the call.

How do we fix this?  The Lync client is not doing this, why is the phone???

It turns out that there are hardware load balancers in use here for the 2 edge servers.  Affinity\persistence for the internal edge VIP was not configured.  This was not a problem for months because the load balancing method was wrong.  It was configured to reach a threshold before sending connections to the other edge server.  When this was corrected, and the method was changed to "least connection", it exposed the affinity issue.

The Lync client is smart enough to never send 2 different addresses in the same candidate pair.  Apparently, some of the IP phones are not.  The IP phone also did not validate the candidate list before connecting the call.  2 IP phones could make calls to each other, even though they had 2 different IP's for the same candidate.

Configuring affinity\persistence on the VIP fixed the issue.

1. Install Lync FE prerequisites as described here:  https://technet.microsoft.com/en-us/library/gg398103.aspx
2. Import the pool certificate with private key on the rebuilt server
3. Use the process documented here to add the server to the topology and publish it:  https://technet.microsoft.com/en-us/library/jj205153.aspx.  Do not restart the servers yet. 
4. Open the deployment wizard on the rebuilt server, select Install or update Lync server, and run steps 1-5
5. Restart all FE's one at a time starting with the newly added server. 
6. Once all servers are up, run "get-csmanagementreplicationstorestatus".  After everything shows "true" in the output, run "get-cspoolfabricstate -poolfqdn <poolname>".  -type routing verbose.   If all groups look evenly distributed move on to the next step.
7. Run "get-cspoolupgradereadinessstate".  If the state of the pool is Busy, wait until it shows Ready to move onto the next step.
8. On the server you added back to the pool, run "stop-cswindowsservice -graceful".   Run "get-cswindowservice" to view service state.  Once all services are stopped, you can proceed to the next step. 
9. Install the Cumulative Update that is currently on the other FE's in the pool. 
10. Install all SQL Express updates that are installed on you other FE's.
11. Reboot the server.  Run the cmdlets from step 6 to verify replication and the fabric are healthy,

There is a caveat to this process...if you are going from a 1 or 2 server pool to any other server count (from 2 to 3, 1 to 4, etc).  If that's the case, you must run "Reset-CsPoolRegistrarState-ResetType FullReset -PoolFqdn <PoolFqdn" after step 4 and before step 5.  Running this cmdlet can take a very long time.  The pool services will slowly come on line after this cmdlet is ran.  Be aware that there may be significant down time as this occurs.  This should be done in a planned maintenance window.