SKYPE FOR BUSINESS 2019 – Deployment Notes, so far…

Well, just some quick notes so far with some deployments of Skype for Business 2019 that I will hope to expand on in the future

  1. S4b enterprise deployments using a SQL server failover cluster (Not AlwaysOn), actual single-disk-shared-with-two-nodes clusters, do not support Cluster Shared Volumes (CSV). When using a CSV, there is no admin share, e.g. E$, in which to use to install the Databases.
  2. When migrating from Lync 2013 environment, replication to the Edge server may fail if TLS 1.0 and TLS 1.1 is actually disabled on the Edge server. Strangely enough, replication with the Sfb2019 pool servers with TLS 1.0 and 1.1 disabled does work.
  3. There’s an immediate change for Online voicemail when you move a user over to an 2019 Edge pool
    Skype4b 2019 – RTCC/ LyncTeamsGateway/
    Skype4b 2015 – RTCC/ MSExchangeUM/15.20.2263.016
  4. CU1 changed show-csclslogging to only display the local server settings instead of the whole environment, breaking the CentralizedLoggingTool.ps1 script of James.
  5. the 2019 ClsLogger.exe tool is incompatible with Lync 2013 coexistence, so I’m finding you have to run it only for the 2019 servers, and on the Lync server run the CentralizedLoggingTool.ps1 for the Lync side.
  6. Sfb 2019 onPrem now includes CsIPPhonePolicy in it’s world. Moving users with VVX phones cause the BToE Pairing to switch from Auto to Manual, yet moving the user back to Lync 2013 the phone switched back to Auto. To adjust: Set-CsIPPhonePolicy -BetterTogetherOverEthernetPairingMode:Auto
  7. IF you have Skype for Business Mac clients, check/re-check your CsPlatformServiceSettings, specifically the EnableFileTransfer. One greenfield and two upgrade projects have set this to False. Sfb 2015 environments are True. Other settings also appear to be changed, check and document before upgrading to Sfb2019.
  8. Get-CsPoolUpgradeReadinessState is gone, and replaced with Get-CsUpgradeDomainInfo I apparently missed the notification on that one…

Skype For Business 2019 CU1 – My Notes So Far

Skype for Business 2019 CU123 (aka CU1) was released this month and one of the features I have been most looking forward to is the Response Group Service becoming apart of the Pool Pairing backup service. To date when planning for Disaster Recovery or Geo-Redundancy, we have had to use a combination of Lync/Skype’s Pool Pairing and a backup of the Response Group Configuration.

I am happy to report that the Response Group Configuration is now apart of the Pool Pairing backup service. I will be following up with a blog post shortly on the process. Of importance though, because CU1 appears to update just about every single component of Sfb2019, any time you enable Pool Pairing, you will need to apply/reapply the latest CU1 or higher update. In my testing and breaking things, if you apply the CU and then enable pool pairing between two pools, your backup services will not successfully start. Planning for Pool Pairing must now include an outage window for you to shutdown the services and apply the latest CU. Looking in the past at Skype and Lync, it doesn’t appear that the Backup Services have ever been updated, they both to this day appear to be RTM.

Another bit of good news, not really CU1 related, but still happy to report, failing over the CMS database no longer appears to be an issue. If you followed Mark Vale’s post on the issue, or Shawn Harry’s resolution, you’ll be thrilled to know I have invoked the CMS and Pool failover no less than 8 times without any problems. I’m also happen to report the the CMS failover is also very quick now too, less than 5 seconds in my crappy lab, you have to wait a little longer for the Replication Status to become true again, 5-10 minutes but I can easily live with that. Heck, I just did it while writing this post.

Unfortunately the posted article didn’t make note of the additional Windows Features that need to be added. The 2019 System Requirements as of July 16, 2019 haven’t been updated yet, but in my deployment I needed to add the following on the Frontend pool servers:

Add-WindowsFeature ManagementOData,Web-Mgmt-Service,Web-WMI,Web-Lgcy-Scripting,Web-Lgcy-Mgmt-Console

Pat Richard found in his implementation he also needed additional entries, so be mindful when applying the CU or running Bootstrapper, look for the warnings, but it’ll depend on your starting point what you might be missing.

This is currently my Frontend features list:
Add-WindowsFeature RSAT-ADDS, Web-Server, Web-Static-Content, Web-Default-Doc, Web-Http-Errors, Web-Asp-Net, Web-Net-Ext, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Http-Logging, Web-Log-Libraries, Web-Request-Monitor, Web-Http-Tracing, Web-Basic-Auth, Web-Windows-Auth, Web-Client-Auth, Web-Filtering, Web-Stat-Compression, Web-Dyn-Compression, NET-WCF-HTTP-Activation45, Web-Asp-Net45, Web-Mgmt-Tools, Web-Scripting-Tools, Web-Mgmt-Compat, Server-Media-Foundation, Telnet-Client, ManagementOData, Web-Mgmt-Service, Web-WMI,Web-Lgcy-Scripting, Web-Lgcy-Mgmt-Console

The main reason for the additional Windows Features is for the HTML5 dashboard. Gradually Sfb2019 will be moving away from the Silverlight dashboard, but it is far from complete as of yet. And oddly, the account you use to sign in must be SIP enabled… Not a big fan of Admin accounts being enabled in Skype, and to me a security no-no, so I was a bit surprised at this requirement. Even with this release, this functionality is still Preview and limited to User changes.

And yah, there’s something about SEFAUtil functions now being integrated as PowerShell commands, blah blah blah… I’m positive the race is on to update the SEFAUtil GUI into an even more powerful tool, so I look forward to seeing who is going to post an update for that in the hopefully near future.

VVX phones and MS Teams

A bit of an odd struggle the last week as I finally decided to try and get my VVX 601 working with MS Teams, without any luck. My account is Teams Only and my VVX should work with the voice interop, but I could only make outbound calls, inbound calls would not ring to my VVX phone.

I then began the process of elimination of what could be in my FTP Provisioning config that messes things up. I’ve developed a rather extensive list of settings to improve the user experience, and correct some rather odd default functionality in my opinion, but whatever.

Anyway, process of elimination, looks like a legacy entry,
Disable this parameter to use Polycom phones with Microsoft Skype for Business Online and Exchange Online
Changing it back to the default of “1” or just removing it, allowed me to both make and receive calls. Seems like a setting that should still be a “0” considering it is connecting to both SFBO and ExO, but the last documented reference that I can find goes back to the 5.4 firmware, but it was still been listed in the polycomConfig.xsd up until 5.9.0. Looks like it was retired out in 5.9.1 and higher. I was performing my testing with the 5.9.3 codes of course.

Another interesting tidbit, when you are using the VVX phones with Teams Only and perform a firmware update, the user may need to go through the Web Signin process again. Seems to vary on the firmware.

Additional note, in my testing Microsoft Teams with my VVX 601, I was unable to sign in with the 6.0 firmware. It sticks on the screen at “Failed to fetch the user certificate”. The possible clue that 6.0+ isn’t for Teams for SFBO is that there isn’t a CAB file to download, but IF you find success with 6.0 or higher firmwares and logging into Teams, please let me know and I’ll update my post.

Additional Basic Testing: – Successful Web Signin, inbound, and outbound calling – Successful Web Signin, inbound, and outbound calling – Successful Web Signin, inbound, and outbound calling – Successful Web Signin, inbound, and outbound calling – Successful Web Signin, inbound, and outbound calling – Successful Web Signin, inbound, and outbound calling – Failed to sign in

OAuth 2.0 – 3PIP Authorization

Just posting the links as they come available for authorizing vendors of choice in regards to the Microsoft posting about new requirements for OAuth 2.0 and certified 3PIP phone.

Missing from the article is if Exchange Online with Skype on Prem (non-MFA) are also impacted. Two of the permissions are directely related to Reading and Reading/Writing to Users Calendars. So, either be proactive, or prepared to make the changes to your Tenant by July 1st 2019 Jan 15, 2020 July 15, 2020 Postponed until further notice.

Jan 8, 2020 Update: I’ve had a couple customers experience issues with Exchange Online if they’re running Trio firmware 5.9.1 and higher, and VVX firmware 5.9.4 and higher since the middle of Oct 2019. I am uncertain what will happen on Jan 15 2020 and if ExO will also enforce fully the OAuth2 requirement like SFBO, but be prepared in the worse case scenario that you need to update the firmware and Approve the 3PIP phones to reconnect your devices to ExO, even if you are Skype for Business OnPrem.

Easy summary, IF you are running the most recent versions of firmware, (e.g. VVX 5.9.4+ and higher) and are using ExchangeUM Online or SFBO/Teams, you must perform the Azure Authorization for your device vendor(s) for them to function properly. The newer firmware’s ONLY support OAuth 2.0, which require the Authorization, and the older firmware’s ONLY support OAuth 1.0 which will cease to work with Online systems in July (currently)…

And no in no particular order:

AudioCodes –

Crestron –

Poly (aka Polycom) –


ThinkTel SIP Trunk Configuration

I have been deploying ITSP SIP Trunks for the last 9 years now, mainly ThinkTel (Canada) and occasionally IntelePeer (US). Today I will be only talking about Direct to Lync/Skype SIP Trunks, and primarily with ThinkTel in mind with a couple of caveats for IntelePeer. As a best practice, I always create a specific PstnGateway configuration for each gateway, even if there is only one.

ThinkTel “PBX” selections come in a couple of flavours, but you basically want to select either “Microsoft Skype for Business w/E.164” or “Skype for Business /restricted direct media” . The main difference between these two PBX types is the former is full E.164 and the later is not. Translation, one sends the +1 the other does not and only sends the 10-digit number. The benefit to only getting 10 digits like an old school PRI line (throwing a little shade there) is the option to now use an MSPL script to block on CallerID. My previous attempts to use this on E.164 traffic failed

General Overview:
1) REFER and Media Bypass are not supported with ThinkTel SIP trunks.

2) Enable the Session Timer, and disabled the RTCP Active Calls and RTCP Calls on hold.
– Not changing these settings can result in calls dropping in the 45-50 minute range, or parked calls dropping after 90 seconds instead of returning to the person who parked the call.

3) Disable the Fast Failover Timer
– Leave this enabled on the Global configuration, but disable on the specific trunk configuration. This may be a non-issue globally anymore but once upon a time there was an issue when the Edge server was down and IF you called a number that was stored in AD some where, like a mobile number on a user, the call would fail if the Fast Failover Timer was not enabled.
– Leaving enabled on the specific trunks, can result in the the gateway being unnecessarily marked down when the call takes longer than 2.5 seconds to set up. Search for Event IDs 46009, 25039.

4) Change the Failover Timeout value from 10000 to 15000 or 20000 ms. (10 seconds to 15 or 20 seconds)
– OCS days, this was 30 seconds, then with Lync they changed to 10 seconds. Not normally a problem, except for International Call setups which sometimes takes longer than the default 10 seconds.
Modifying the FailOverTimeout

Below are suggested PS Command to set your ThinkTel SIP trunk configuration. Make note of what your settings currently are. I never just use/rely the Global Trunk Configuration for ITSP trunks, and specifically on the Global I leave REFER enabled, SRTPMode as Optional, and the EnableFastFailoverTimer to enabled. Which command(s) you need to use will be dependent on your environment, so use Get-CsTrunkConfiguration to see what you have and what your settings currently are.

Set-CsTrunkConfiguration -Identity -EnableReferSupport:0 -EnableSessionTimer:1 -RTCPActiveCalls:0 -RTCPCallsOnHold:0 -SRTPMode NotSupported -EnableFastFailoverTimer:0 -EnableBypass:0

Set-CsTrunkConfiguration -Identity -EnableReferSupport:0 -EnableSessionTimer:1 -RTCPActiveCalls:0 -RTCPCallsOnHold:0 -SRTPMode NotSupported -EnableFastFailoverTimer:0 -EnableBypass:0

Set-CsTrunkConfiguration -Identity Service:PstnGateway: -EnableReferSupport:0 -EnableSessionTimer:1 -RTCPActiveCalls:0 -RTCPCallsOnHold:0 -SRTPMode NotSupported -EnableFastFailoverTimer:0 -EnableBypass:0

Set-CsTrunkConfiguration -Identity Service:PstnGateway: -EnableReferSupport:0 -EnableSessionTimer:1 -RTCPActiveCalls:0 -RTCPCallsOnHold:0 -SRTPMode NotSupported -EnableFastFailoverTimer:0 -EnableBypass:0

Firewall Rules that you will need are below. Replace with the Public IP of your own Mediation server. There can be no SIP ALG, SIP Inspect, port remapping, or or anything else of the sort that may mess with the ports, or you may experience one-way or no audio at all issues, and/or unexpected call drops after 30-45 seconds.

IF you are using a NAT translations, please check out my other post on one-to-one bidirectional static NAT’s and avoid some of the pitfalls there.

The main caveats for IntelePeer is when requesting the SIP trunk, you specify that it is for a Lync/Skype environment and that they need to make sure the SIP traffic is set to TCP and not UDP which is their default. I’ve heard that their new SIP infrastructure may not support SIP over TCP and you may have to specifically request the legacy infrastructure. You will also want to set the SIP Trunk Configuration RemovePlusFromUri =True, especially if you are making International calls. Otherwise I’ve found the same Trunk Configuration for ThinkTel works for IntelePeer.

Teams Migration Prep – Part 2 – UPN/SMTP/SIP Alignment

Cleanup and Rationalization: always a fun part of any project. Microsoft Recommends keeping your UPN and SMTP email address the same, and now for Cloud Voicemail, your SMTP and SIP addresses also need to be the same. There are also potential impacts and confusion when it comes to MFA. MVP’s now tell me that UPN/SMTP/SIP all matching is just “assumed knowledge” now.

What I’m providing today are some PowerShell commands to help flush out the mismatches. Pat Richard has in the past provided a handy one for finding Onprem users where the Mail address and SipAddress do not match.

Get-CsAdUser | Where-Object {($_.WindowsEmailAddress -and  $_.SipAddress) -and ($_.WindowsEmailAddress -ne ($_.SipAddress -replace  "sip:",""))} | Select-Object DisplayName,WindowsEmailAddress,SIPAddress 

Once upon a time though, setting the email address on the General tab of a AD user object, also set the primary SMTP: (vs smtp:) address in the proxyAddresses attribute. A bug report I filed back in the 2005 range, modifying the email address field on the General tab could result in a duplicate email address, I presume that this is why now that this attribute is really only for display purposes, and could be wildly different than the SMTP: setting of proxyAddresses. Sorry Pat, I’m having to retire your command.

In with the new, and the ugly. I’m am not a coder, and I’m sure Pat will find a clever way to improve the following PS Commands. Thanks to proxyAddresses being a Multi-Valued String attribute, nothing is easy.

UPN / SMTP Mismatch – where the UPN and SMTP addresses do not match

$userResults = Get-ADUser -Filter {enabled -eq $true -and mail -like "*"} -Properties displayName,userPrincipalName,mail,proxyAddresses | Select-Object displayName,userPrincipalName,mail,proxyAddresses,@{n="proxyAddress";e={$_.proxyAddresses | Where {$_ -clike "SMTP:*"}}}

$mismatchResults = $userResults | where{($_.proxyAddress -replace "SMTP:","") -notmatch $_.userPrincipalName}

$mismatchResults | Sort-object {$_.DisplayName} | format-table DisplayName,userPrincipalName,mail,proxyAddress

$mismatchResults | Sort-object {$_.DisplayName} | Select-Object DisplayName,userPrincipalName,proxyAddress,mail | Export-Csv -Path C:TempMismatchUPNSMTP.csv -NoTypeInformation

SMTP Mail Mismatch – where the Mail (WindowsEmailAddress) and the primary SMTP: address do not match (display purposes mainly)

$userResults = Get-ADUser -Filter {enabled -eq $true -and mail -like "*"} -Properties displayName,userPrincipalName,mail,proxyAddresses | Select-Object displayName,userPrincipalName,mail,proxyAddresses,@{n="proxyAddress";e={$_.proxyAddresses | Where {$_ -clike "SMTP:*"}}}

$mismatchResults = $userResults | where{($_.proxyAddress -replace "SMTP:","") -notmatch $_.mail}

$mismatchResults | Sort-object {$_.DisplayName} | format-table DisplayName,mail,proxyAddress,userPrincipalName

$mismatchResults | Sort-object {$_.DisplayName} | Select-Object DisplayName,mail,proxyAddress,userPrincipalName | Export-Csv -Path C:TempMismatchMailSMTP.csv -NoTypeInformation

UPN SIP Mismatch – where the SIP and UPN address do not match

$userResults = Get-ADUser -Filter {enabled -eq $true -and mail -like "*"} -Properties displayName,userPrincipalName,mail,proxyAddresses | Select-Object displayName,userPrincipalName,mail,proxyAddresses,@{n="proxyAddress";e={$_.proxyAddresses | Where {$_ -clike "SIP:*"}}}

$mismatchResults = $userResults | where{($_.proxyAddress -replace "SIP:","") -notmatch $_.userPrincipalName}

$mismatchResults | Sort-object {$_.DisplayName} | format-table DisplayName,userPrincipalName,mail,proxyAddress

$mismatchResults | Sort-object {$_.DisplayName} | Select-Object DisplayName,userPrincipalName,proxyAddress,mail | Export-Csv -Path C:TempMismatchSipUPN.csv -NoTypeInformation

SIP SMTP Mismatch – where the SIP and SMTP addresses do not match (important for Cloud Voicemail, these need to match I’m told)

$userResults = Get-ADUser -Filter {enabled -eq $true -and mail -like "*"} -Properties displayName,userPrincipalName,mail,proxyAddresses,msRTCSIP-PrimaryUserAddress | Select-Object displayName,userPrincipalName,mail,msRTCSIP-PrimaryUserAddress,proxyAddresses,@{n="proxyAddress";e={$_.proxyAddresses | Where {$_ -clike "SMTP:*"}}}

$mismatchResults = $userResults | where{($_.proxyAddress -replace "SMTP:","") -notmatch ($_.'msRTCSIP-PrimaryUserAddress' -replace "SIP:","")}

$mismatchResults | Sort-object {$_.DisplayName} | format-table DisplayName,proxyAddress,msRTCSIP-PrimaryUserAddress

$mismatchResults | Sort-object {$_.DisplayName} | Select-Object DisplayName,userPrincipalName,proxyAddress,msRTCSIP-PrimaryUserAddress | Export-Csv -Path C:TempMismatchSipSMTP.csv -NoTypeInformation

A person can obviously play around with the commands a bit. I’ve included both a screen output and a csv export, you don’t need both if you don’t want to.

I take no responsibility for how you have to clean up any mismatches in order for you to get everything aligned. SMTP is not usually a big deal, you can have multiple smtp addresses, but only one default SMTP:. SIP, well, if you have to change this one, that’s not fun, as everyone who is subscribed to that users presence will not see them anymore until they re-add them with their “new” SIP address. Changing the UPN, that naturally changes how they sign in to Office 365 and potentially your environment, BUT if you’ve caught this early enough and you are only now prepping to start moving to Office365 (Exchange or Teams, not supposed to talk about SFBO anymore, shush).

Teams Migration Prep – Part 1

In part, I’m documenting this for myself cause I have swiss cheese memory right now. So as I encounter problems with moving, or getting ready to move users from Skype for Business OnPrem to MS Teams, putting to paper tends to help me remember. I have though searched for issues, only to have my own blog posts come up, which is good, but also a sad commentary on the aging brain…

Anywho, issue resolution today, I was running the following command to assign online policies to Users, premove:

Get-CsOnlineUser | set-csuser -EnterpriseVoiceEnabled $true -HostedVoiceMail $true

And I receive the following error:
“Remote call control, Enterprise Voice, and IP PBX soft phone cannot be enabled when user is not enabled for audio/video”

Assuming that the correct O365 licensing has been set, in this case E5 w/o AC, plus Audio Conferencing, this error was actually caused by the CsOnlineUser attribute “AudioVideoDisabled” was equal to True. Changing to False is what you want:

Get-CsOnlineUser | set-csuser -AudioVideoDisabled:0

The system I am working with is inherited, so I have no idea why 98% of the users are correctly set to False for this attribute, and literally only a handful out of 517 users are properly set is a mystery.

You can search out in your Online environment, users who are going to give you this grief ahead of time. Even though they’re mostly or all OnPrem, AAD Sync’ed users with Skype for Business Hybrid have this attributes set.

get-csonlineuser | where {$_.AudioVideoDisabled -ne $false} | fl DisplayName,UserPrincipalName,Sip*,AudioVideoDisabled

SFBO and switching to VVX Provisioning

Today I decided I wanted to verify what firmware version is being deployed out by Skype for Business Online.  Maybe you’re like me, and have your own FTP Provisioning server, or you are using the Polycom RP Resource Manager.  And considering I was testing out the re-released Firmware for the 5.7 and 5.8 build lines, why not check one more out.  Mash 1-5-3, for an easy factory reset, authenticate the phone, and wait for the firmware update magic to transpire.

As of June 29, 2018, the online build version being deployed is  A fine build I’m sure, but for me, that dog won’t hunt.  It’s almost a year old, it doesn’t support the BToE via the network when the PC isn’t plugged into the phone, nor does it support Common Area Phones with SFBO which I’ve also been messing around with.  Fine, I’m done and I have my answer, so I switch my global config to the

***In case you haven’t heard, there is a high security risk with UCS builds for 5.7.x and 5.8.x. and and higher have been released to resolve this security risk.  Be mindful of the BToE software, 3.7 does not pair with 5.8, and 3.8 does not pair with 5.7.  Please be sure to upgrade your firmware if you are runing 5.7.x or 5.8.x builds.***

Oh look a bird.

Anyways, I flipped my global config to the firmware, re-pointed my VVX 600 back to my FTP Provisioning server, hit Save, phone takes in my configs, reboots, but no firmware updating…  Couple more reboots, nothing.  What the smurf…

Logs…, specifically the boot log, phone is still checking online for firmware updates (‘https://PlcmSpIp:****’) oh look,….

Off to dump the Device Settings of the phone…  device.prov.upgradeServer is set to https://webpoolsn1…. yadda yadda.

Easy enough to fix though, just added additional settings to my custom config to set and null the upgrade server setting.

Update Configuration one more time, and boom, firmware update.

Summary:  If you are using VVX phone with SFBO, and feel the need to use newer firmware, be sure to add the above lines to your config so you can pull away from SFBO.  You will also need these parameters if you don’t already to prevent the phones from getting firmware and inband settings from Skype for Business onPrem Servers or Online:

Happy Provisioning.

SFBO AutoAttendant Holidays

Good news, it’s the Canada Day long weekend is here so naturally have have some things to blog about which no one will read before the long weekend…

One of my clients has been working with Skype for Business Online’s Auto Attendants and Call Queue, and with the long weekend a head wanted to set the Reception AA to route calls to an after hours type IVR.  They unfortunately received a “This field is required” error message, even though they’ve selected and item from the drop down list.

On a hunch, and maybe Michael said something, I don’t remember, I pulled in an additional Service Number on the Voice | Phone Numbers, and then assigned it to the after hours IVR in question that was failing.  Apparently the “required field” is perhaps a LineURIs on the AA object in this case to populate the TargetId.

Running Get-CsOrganizationalAutoAttendantHolidays reveals an interesting CallAction, hence my assumption that the LineUris is a required field, or at least as it currently stands.

Of course as I’m writing this out, Michael goes and figures out how the PS commands to set the TargetId to a SIP address instead, I’ll let him post on that and link from here if/when he does.  Easiest course of action is to aquire and assign a Service Number, at least until they MS Online perhaps fixes it so that IF there isn’t a LineUris, then use the PrimaryUri.

You may also be wondering, “How many Phone Numbers and Service Numbers can I get“, well, there’s a link for that.  There is a PS Command, Get-CsOnlineTelephoneNumberAvailableCount which gives you a total count, but doesn’t break down the service vs subscriber vs toll free counts available.



Quick blog about locking handsets in a Skype for Business environment, Online and for OnPrem, for the more security minded clients that do enforce phone locking when the PC is locked.

For Lync Phone Editions and Polycom VVX series phones running with the BToE pairing, and you are enabling/enforcing the Phone Locking feature, you kind of expect the phone to be “Locked” and unable to make calls.  Recent testing a client discovered that all you had to do was pick up the handset and you could still make a PSTN or even a SIP call.

Jeff blogged about this back in 2012, Locking Lync Phones, and it is still required today both online and onprem IF you want to prevent locked phones from actually being able to make calls.  It’s a simple matter of setting the CsClientPolicy:  DisableHandsetOnLockedMachine:$True

For adjusting the Global policy online, it took a good 1-2 hours before it took effect on the phone.

With the VVX series, and a provisioning server, you can add Authorized Numbers to the VVX config so that certain numbers like 911, Security, Reception for example.  Below is a code snippet you would use in your Provisioning config file(s):

<phoneLockAuthorization phoneLock.authorized.1.description=”Security Desk” phoneLock.authorized.1.value=”2505551212″ phoneLock.authorized.2.description=”911″ phoneLock.authorized.2.value=”911″ />

Personally I think it’s a little odd that DisableHandsetOnLockedMachine is false (null) by default.  I would have thought a locked phone is a locked phone, but feel free to tell my I’m nuts for thinking so.

Unified Communications and Collaboration