Windows 8.1 Apps Won’t Update

80070490For the past year or so, my home Windows 8.1 PC wouldn’t update most of the apps. So as Microsoft has slowly improved the Music app, I’m not getting any of those benefits. Heck, the apps wouldn’t even start.

Every so often I would spend an hour or two trying to fix this, eventually giving up and hoping the inevitable Windows 10 upgrade will fix it. Last night I spent way too much time on this problem. I spent over 4 hours trying to fix it.

I spent the night Googling/Binging and trying everything I could find.

Wsreset didn’t fix it.

SFC /Scannow didn’t fix it but it did send me on a side project to figure out why that was failing. SFCFix with some sfcfix.zip file fixed that problem. My apps still wouldn’t update.

I smoked the C:WindowsSoftwareDistribution folder a few times.

AppsDiagnostic.diagcab and app.diagcab? Ran those along with WindowsUpdateDiagnostic.diagcab with no fix for the issue.

I tried a bunch of other things so let me skip ahead.No Update Apps

I tried uninstalling the Apps form Windows Store but I couldn’t. It wouldn’t let me click on the apps at all – it just showed them on the list. So I figured I would try to manually uninstall them hoping a re-install would fix them.

That brought me to this article – http://all4naija.blogspot.com/2015/04/how-to-remove-microsoft-apps-using.html

While the article says it’s for Windows 10, it worked like a champ on windows 8.1. I had the list up of my failed updates and then pecked around via PowerShell to delete them. Once I got them all uninstalled, I rebooted and went to install them again. While it took a long time, they all started installing and were working fine.

So that problem is (mostly) fixed. There are three apps still in the list that wont update. But that is a huge improvement over what I had.

My theory is that they were in Windows’ list of “installed apps” but they weren’t actually installed. So when Windows tried to install the updates, it failed because there was actually nothing to update.

————————————-

For the search-ability reasons, here are some of the errors I had and couldn’t resolve using any of the popularly recommended issues:

0x80070002

0x80070490

80246007

Event Viewer Event ID 1001

Problem signature: P1: 9600 P2: 788 P3: 115 P4: 1 P5: US P6: en-US P7: 120 P8: -2147023728 P9: Microsoft.BingFoodAndDrink_8wekyb3d8bbwe P10: 0

Fault bucket , type 0 Event Name: WindowsStoreUpdateFailureV2 Response: Not available Cab Id: 0

 

Calls Not Completing for user with “Non-Western European” characters

This topic has already been covered in Spanish here  and in German hier.

I am just adding an English language version because I recently ran into the same issue and there is no blog in English about it.

If I ever wondered why we buy support from gateway vendors, this issue validated it for me.

We were bringing up a new location with a PRI. Through testing, I was able to make outbound calls but the people in the actual location were unable to complete the calls. This didn’t make sense. How can I make a successful call, sitting thousands of (pick one: miles/kilometers) away, and the people in the actual office could not?

In this case, our gateway was an AudioCodes Mediant 1000 and we were working with an AudioCodes engineer on the implementation. The AudioCodes engineer had given us numerous things to try to no avail. Finally he had us e-mail him some WireShark logs so he could spend more time on the issue.

A day later, he recommended that we set this value in our ini file:

ISO8859CharacterSet = 0

After making this change, the users in the location were suddenly able to make calls.

The issue is that the users in that location all use the following character in their display name as part of the spelling of their office location:

è

So what does this ISO8859CharacterSet value actually mean? For one, it’s not documented anywhere. I followed up with AudioCodes and they sent me the following documentation.

ISO8859-charset

 

Basically, this value expands the default character set that AudioCodes uses to parse SIP traffic. Why isn’t it set to zero by default? Who knows. I asked that question to the AudioCodes engineer and he had no answer. I asked if maybe there was a performance impact to this value. He replied that there isn’t one that he knew of. I asked a second AudioCodes engineer and he confirmed that he had never heard of an issue by setting this to 0.

It’s surprising to us that we hadn’t run into this issue before but then our standards are to use the generic ASCII character set in all display names, usernames, etc.

How do you know you might have this issue? I don’t have the AudioCodes syslog files anymore so I swiped the below from the German blog mentioned above.

 

<132>[S=831454] Error Indication: Last Command (Primitive) was not performed due to cause 100  [Trunk:0 Bchannel:1 ConnID:2] [Code:0x23127]
<133>[S=831455] (   lgr_psbrdex)(833974    )   recv <– UnHandled event:EV_ISDN_ERROR_INDICATION (317)
<133>[S=831456] [SID:766997237] (   lgr_psbrdex)(833975    )   pstn recv <– CALL_RELEASED Trunk:0 Conn:2 RetCause:73 NetCause:255
<132>[S=831457] REPORT_TYPE_ERROR_IN: ErrorCauseString = Incorrect parameter type, DiagnosticString= Condition unknown, ErrorCause = d, Diagnostic =  [Trunk:0 Bchannel:-1 ConnID:-1] [Code:0x23127]
<133>[S=831458] [SID:766997237] (   lgr_psbrdif)(833976    )   pstn send –> PlaceCall: Trunk:0 BChannel:1 ConnID:2 SrcPN=xxx SrcSN= DstPN=151xxxxxxxx DstSN= SrcNT=4 SrcNP=1 SrcPres=0 SrcScrn=0 DstNT=2 DstNP=1 ServiceCap=M RdrctNum= RdNT=0 RdNP=0 RdPres=0 RdScrn=0 RdRsn=-1 Excl=1 Display=Müller, Max IE= UUIE=0, RawData:0 CLIRReason:-1 OrigPN= OLI=-1 OffhookInd=0
<133>[S=831462] [SID:766997237] (   lgr_psbrdif)(833980    )   Abnormal Disconnect cause:255#?reason(255)? Trunk:0 Conn:2

 

If you see the above that’s a clue. In this case, it was the u-umlaut (ü) in “Müller, Max” causing the issue.

Quick RegEx Trick

AnientRegExI thought I blogged this but I guess I didn’t. So I am posting this mostly to save myself time finding this the next time I look for it.

I had a regular expression that returned 2 variables. Here is what I wanted:

$1555$2.

However Lync interprets “$1555” as a variable instead of what I want which is just $1 as the variable. So how do I tell regular expression that it should stop at the first 1 and not continue until the next delimiter ($2)?

Answer:

Use curly braces

Re-writing it in this format got me the desired result:

${1}555$2

The fourth paragraph on this website is what got me the answer – http://www.regular-expressions.info/replacebackref.html

Script: Query Front Ends for Specific Event Log ID’s

I was troubleshooting today with my main Lync man “JP” (who chooses to remain anonymous). Part of our troubleshooting was checking against 6 (and sometimes 12) front ends to see if a specific Event ID appeared in Event Viewer. This was tedious, going to each server and then a lot of them getting no results.

JP said “there should be a script to do this for us”.

And from that comment this script was born. It’s possible someone has already written this script. We didn’t bother looking since it is a fairly simple script. If someone has written this, then let me know and I will give you credit.

The script – Get-CsEventID – is pretty simple. There are 2 mandatory parameters:

-Pool is the name of your Lync pool which is then sent to Get-CsSite to get the names of each of the servers in your pool

-EventID is the Event ID for which you are looking.

The two optional parameters are:

-LogName By default the script searches in the “Lync Server” log but setting this will let you search against other logs like Application or System

-StartTime If you want to limit your search to the past few hours or days, then set StartTime to the number of hours you want to go back. By default, this is set to 72, so it will search back for the past 3 days.

Here are 2 examples:


.Get-CsEventID -Pool skypepool.flinchbot.com -EventID 12288

This will search for Event ID 12288 across the skypepool.flinchbot.com pool. It will search for the past 72 hours for this entry.


.Get-CsEventID -Pool skypepool.flinchbot.com -EventID 6005 -LogName &quot;System&quot; -StartTime 4

This will search the same pool, but now for EventId 6005 in the System log. It will search back the past 4 hours.

Note that Windows Firewall will need to permit access to remote event logs. You can run the following on a Windows 2012 or later server to enable this.


Get-NetFirewallRule | where DisplayName -like  '* Event Log*' | Enable-NetFirewallRule

Grab the script here.

 

Skype for Business Notes

I’ll be tracking my notes with installing and working with Skype for Business.

1. I did an in-place upgrade of my existing Lync 20reset-cspoolr13 pool and everything started up and appeared to be working fine. The upgraded pool is named “lyncpool.flinchbot.com” which is a bad name for a pool that actually contains Skype4B servers. So I decided to reduce that pool from 3 front ends to 1 which will give me enough space on my VM hosts to build some new, native Skype4B servers. So I removed 2 of the 3 front ends via Topology Builder. Now my pool won’t start. I get the following error when try to do a full reset of the pool:

poolfail

Fabric version is unknown. No it’s not. It’s what came on the install image! It’s version 3.

Good ol’ Windows Fabric strikes again. I’ve tried rebooting and forcing the reset a few times. Finally I uninstalled Windows Fabric and installed it again from the Skyp4B .iso. Same problem. So this pool is hosed and since this is a lab I don’t want to spend any more time figuring this out.

Update: As I removed roles from Topology for this pool, like conferencing and enterprise voice, I tried to start the service again. It finally started. It is possible that re-running the deployment wizard straightened a few things out. I’m wondering if running Enable-CsComputer separately would have fixed it too.

My takeaway: Don’t do in-place upgrades of production machines. Now this error may not be related to the in-place upgrade process. However, doing a fresh install assures that you can test the pool before moving users. It also gives you the chance to do things like installing the latest OS, building it on newer hardware, installing the latest Windows patches if you’ve fallen behind, etc.

2. Control Panel still can’t sort. This is about unacceptable. Seriously Microsoft? You can get media to traverse NAT’s, firewalls, edge servers, etc but you can’t sort a list? You’d think by the 3rd release of the Lync line of software that they could get some intern to show them what he learned in his first programming class ever: How to sort a list. At work we have admins scattered all over the place, a few dozens pools, and more supported SIP domains than I want to count.. Trying to find the right entry in some of our lists is very difficult and frankly a waste of my time.

Sorting is hard

Sorting is hard. It’s like math but hardererer.

3. When adding your Skype4B server to Topology, be sure to put them in the Skype for Business folder. I know, this should be obvious but I guess habit got the better of me. I added my Skype4B Enterprise settings into the Lync 2013 foled in Topology. To no surprise, I got the following errors in the install logs:

Wrong-folderSo if you get this error, remove the Skype servers you put into the Lync 2013 folder and add them again to the Skype for Business folder. Removing them from Topology might give you an error that a conference directory already exists on the pool you are trying to delete. Delete that by running the Remove-CsConferenceDirectory  with the -force switch and then try the Topology removal again.

4. Not everything is a straight port from Lync 2013 with the “Skype Look”. The certificate wizard was actually simplified and I like it better.

certreq

They also updated the “Start Services” text to explain that you really shouldn’t start the services until your pool is ready. It’s a minor fix but I bet it will reduce some of their support calls.

startservices

What they should also add in there is when running Start-CsPool that it must be done form a shell opened to “Run as Administrator”

5. There is no way to in-place upgrade an SBS/SBA. While this would have been *really* useful and possibly the only use of in-place upgrades I would have used in production, Microsoft doesn’t support this. My guess is that this is because Microsoft foolishly still makes the SBA vendors provide custom (and wholly redundant) “Install code” which could fail to function in an upgrade scenario. This is yet another reason why the SBA/SBS model is excellent on the drawing board but is full of issues and miss-steps in production.

So much like the upgrades from 2010 to 2013, you have to do full re-installs to get to up to Skype4B. The SBA code hasn’t been released yet because of the reliance on 3rd party vendors to provide their no-value-add install wizards. An SBS does not rely on this pointless vendor integration so you can upgrade those on your own – full uninstall of Lync followed by the Skype4B install off the .iso.

6. That annoying 29820006 patch. You can’t install it. Oh you keep trying. Then you realize it’s the x86 patch. So you download the x64 patch and it still won’t install. So I’m not sure exactly what the magic is, just make sure everything in Windows Update that is mandatory or recommended is installed. I think there is an update to Windows Update that has to be installed before you can install this patch.

 

Announcing the UC Now apps!

A few years ago I created a Lync “aggregator” which scours 120+ blogs and other related sites for Lync articles and posts what it finds to various places. You can see the output in Twitter, Twitter again, Bitly, Facebook, Google+,  Tumblr, and in various apps I’ve put out over the years. I’ve also added a less-complete aggregator for Exchange which you can see on Twitter.

I’ve unpublished all my previous Windows Phone apps and now have a universal app called UC Now that is the same app on Windows 8.1 and Windows Phone 8.1. Here is the link to the Windows store and here is the link to the Windows Phone store.

For those on Android devices, you can download the Lync News 2013 app which will get you by until I can get that updated to add the Exchange feeds and a bit more in-line (at least content-wise) with the Windows apps.

If you are using an iPhone then you are hosed. But you probably already new that.

Below are some quick screen shots from the Windows 8.1 app.

Main page

Main launch page

Exchange news feed

Exchange news feed

Skype for Business (Lync) news Feed

Skype for Business (Lync) news Feed

Resource links

Resource links

The Windows apps were done using Microsoft App Studio. The Android app was done using AppYet.

If you have any of the older Windows apps installed, please uninstall them as they will never get updated.

Auto Answer on Polycom VVX phones

An admin at one of the sites I help support asked me the other day if there is a way to have a Polycom handset automatically answer a call. I was initially confused as to what he meant. I thought maybe he meant forwarding the call to an AutoAttendant or another extension. (There is a language barrier here too so something may have gotten lost in translation.)

Because seriously: What is the point to have a handset auto answer a call? The person calling the phone will just talk to no one?

Well that is exactly the point. Essentially, this is a “budget” paging function which is what the admin at the remote site wanted to know.

I did some digging and the Polycom VVX phones support this feature natively. I won’t go into the details on how to set this up as you can read this document for the full details. (Skip to page 21)

I have successfully tested this on the VVX 310 and the VVX 500. You call the number assigned to the handset, the phone answers, and any rubbish you say comes out of the speaker on the phone.

If you are interested in a proper paging solution with groups and fancy features using the VVX phones, then check out this article on Anthony Caragol’s Lync/Skype Blog

Deep Dive into the Set-CsPinSendCAWelcomeMail Cmdlet

mr-mrs-atm-pinWe are rolling out a big dial-in conferencing project. As a good percentage of our users are not yet enabled for Enterprise Voice we are doing a lot of discussing and testing about how to get those users their PIN numbers.

Without a LineURI defined, setting a PIN can be a challenge. Check these articles for more detail: LyncBuilder (via Wayback Machine…) or ExpertsExchange We have 2 options that we can think of:

1.) We could rip their defined phone number out of AD and assign that as their LineURI. Then they can go to the dialin page and set their own PIN. The problem here is that there is no guarantee that the number in AD is accurate, valid, and/or properly formatted. Even with EV disabled on an account, as soon as you set LineURI you can right click on a non-EV user and a pop out becomes available to call their work number. This should work fine but again, who knows if AD is accurate, has a valid number defined, and has that number in e.164 format.  Plus this could add some confusion when we do get around to EV enabling the user. Since they already have a lineURI, do we overwrite it? Probably, but….confusion.

2. Assign a random PIN to those users and e-mail it to them. Fortunately, there is a poorly documented Lync PowerShell command that actually does this: Set-CsPinSendCAWelcomeMail. This cmdlet is so neglected it doesn’t even get a proper Technet page like every other cmdlet does. Fortunately, it’s a fairly self explanatory cmdlet. In it’s shortest form, you can generate a random PIN for a user and then send them an e-mail with that PIN using the following syntax:

Set-CsPinSendCAWelcomeMail -UserURI&amp;nbsp;cdiaz@flinchbot.com -from flinchbot@flinchbot.com -smtpserver exchange13.flinchbot.com

The UserURI is the user’s sip address without the “sip:” part. The Set-CsPinSendCAWelcomeMail does a few lookups to find a Lync user that matches this address. Note that if you just use the SamAccountName (cdiaz) or provide a SIP address (sip:cdiaz@flinchbot.com) that the cmdlet will be unable to send the e-mail. (I learned this the hard way!). I haven’t tested to see what happens if the e-mail address does not match the users SIP address but I bet the -UserEmailAddress parameter comes in handy in this case.

The -from field is the usual from field used in e-mail. Set this to an administrative account so when people receive the e-mail it will look “official” instead of coming from some doofus like me. Finally you provide the name of the mail server through which to send the e-mail with the -smtpserver parameter. So far so simple. And I bet you can figure out most of the other parameters pretty easily.

The one that took me some time to figure out is the “-TemplatePath” parameter. What this parameter does is let you pick an alternate e-mail message template than the default one that ships with Lync.

Oh, there is a default one?

This is what the default e-mail looks like. I don’t particularly like the verbiage on the first line because I think it’s wrong. Just because you have a PIN doesn’t mean you can suddenly join conferences. You can join conferences without a PIN.   PIN Default welcome Check out this folder on your Lync server: C:\Program Files\Common Files\Microsoft Lync Server 2013\Modules\Lync

Check out this folder on your Skype for Business server: C:\Program Files\Common Files\Skype for Business Server 2015\Modules\SkypeForBusiness

Inside there is a file called “CAWelcomeEmailTemplate.html”. Open it in Notepad or some other text/HTML editor and take a look. It’s all just basic HTML but I do want to point out that there are 2 variables in this file. If you want to create your own custom templates, you might need to use these:

%URL% – This is the URL to your dial in Simple URL

%PIN% – This is the PIN that was set by the cmdlet

If you only want to make a minor change, feel free to back up the original CAWelcomeEmailTemplate and then edit that one directly. Note that this directory has the annoying security set on it so you need to open your editor as Administrator in order to save back your changes. Also keep in mind that if you have multiple front ends, you’ll have to copy this edited default file to each one of your servers. And then don’t forget to do it when bringing up a new Front End in the future.

After editing the file, I ran Set-CsPinSendCAWelcomeMail again and this is the new message: PIN Edited default welcomeNow if you want to have a separate template, or want to leave the default template alone, you need to use the -TemplatePath parameter. You can’t just copy your changed template into the C:\Program Files\Common Files\Microsoft Lync Server 2013\Modules\Lync directory and just provide the name of your new template. That would be easy. No, you have to provide a full path  (or have the file sitting in your local home folder (i.e. %userprofile% directory)). I suppose there is an advantage to this. Instead of having to copy a file to every front end, you only need to keep it in one location. Anyway, here is the command from above but this time run with the -TemplatePath parameter:

Set-CsPinSendCAWelcomeMail -UserURI&amp;nbsp;cdiaz@flinchbot.com -from flinchbot@flinchbot.com -smtpserver exchange13.flinchbot.com-TemplatePath "c:\temp\MyWelcomeTemplate.html"

When running it, you get something like the following: PIN Edited default welcome PathI hope you read that whole e-mail. Partially because any reference to The Hitchhikers Guide to the Galaxy ought to be read, but mostly for the last few words: “Your PIN has not been changed”. If a user already has a PIN, then this command will not change it.

How to tell if a user already has a PIN: Run Get-CsClientPinInfo -identity <user>. 

So what can you do if you want to use this command but also want to change the PIN no matter what? You can append the -force switch to the command. So running this bad boy produces the output below:

Set-CsPinSendCAWelcomeMail -UserURI&amp;nbsp;cdiaz@flinchbot.com -from flinchbot@flinchbot.com -smtpserver exchange13.flinchbot.com-TemplatePath "c:\temp\MyWelcomeTemplate.html" -force

PIN Edited default welcome Path force Check out the very bottom and you can see that a random PIN was generated.

If you run this cmdlet, doesn’t it seem more like a script than just a cmdlet? That’s because it is a script. Look in this directory:

Lync:  C:\Program Files\Common Files\Microsoft Lync Server 2013\Modules\Lync

Skype: C:\Program Files\Common Files\Skype for Business Server 2015\Modules\SkypeForBusiness

There is a file called SetCsPinSendCAWelcomeMail.ps1. This is the script that actually does all the magic. It’s a really straightforward script. I’m not sure what you might want to edit in it except perhaps defining your own variables like %PIN% and %URL% that you want to add yourself.

There may be one reason that you actually do want to edit this script and that is because the verbose mode is “broken”. Lync MVP Pat Richard even opened an IdeaScale entry for this “feature”. Hacking this file will provide a workaround until Microsoft decides to update this file.

Open the file and remove every occurrence of “-Verbose:$Verbose”.  According to TechNet, -verbose “displays any verbose messages, regardless of the value of the $VerbosePreference variable.” And by default, $VerbosePreference is set to “SilentlyContinue” which means “don’t show verbose messages”

Lync Regions and assigning Dial-In Conference Numbers

RegionsI consider myself really sharp at Lync. However there are still times when I have “duh” moments that I feel like I should have known for years. Since Lync is a pretty complex and varied system there are just some things I never sat down and properly figured out. Dial-In conferencing Regions is one of them. I’ve probably set up dozens of dial-in conferencing numbers over the past few years but there were still a few things I just missed. This article will do a fairly deep dive into Regions and Dial-in Conferencing numbers.

So first off: What is a Region? A Region is anything you want it to be. It’s just some text. A region is independent of an Active Directory site or a Subnet or anything similar. A Region could be “Earth”. A Region could be “Germany”. A Region could be “My bedroom in the basement of mom’s house”. In practicality, a Region is used to define where a dial-in conferencing phone number resides. So if I have a dial in number in Indianapolis and one in Stockholm, the regions could be”Indianapolis” and “Stockholm” or they could be “United States” and “Sweden” or they could be “North America” and “Europe”. The Regions are just a way to let people know where the dial-in conferencing phone number is located.

None of this should be too mind blowing.

So where do you configure these region names? If you answer: “In the same place where you configured the dial-in conferencing number” then you would be wrong. You actually configure them in Dial Plans. There is a reason for this that I will get to later.

In order to set a region, open any dial plan and in the “Dial-in Conferencing Region” box, type in anything you want. In the example below, I entered United States. Also note that this is being set on the “Global” dial plan.

Global_RegionIf we want to see our existing dial-in conferencing Regions, you can run this PowerShell command:

Get-CsDialPlan | Select-Object DialInConferencingRegion

If I run that command I see the following:

Region_List

OK this is great. I have a region. Now how do I assign it to a Dial-In Conference number?

Assuming you don’t have one yet, let me show you quickly how to create a dial-in conferencing number. In Lync Control Panel, navigate to the “Conferencing” section and then the “Dial-in Access Number” tab. Click “New”

Add_DIC

Look at the above image. The “Display Number” can be anything you want. It can be in any format you want. In this case I formatted it to the standard way phone numbers in the North America Numbering Plan tend to be formatted. The Display Name field is really a comment for you the administrator so you know why this number was added. Line URI must be the exact, normalized phone number that Lync will use to answer the call. This number needs to be exactly right. The SIP URI can be anything you want. I often make it match the Line URI but you can use anything you want. The Pool is used to tell Lync which of your Lync pools will receive the inbound call. Finally you can select a Primary language and up to four secondary languages for this dial-in access number.

And where do we define the Region? All the way down at the bottom. I have to scroll down so you can see it.

DIC_Associated_Region

After clicking the Add button you are given a list in which to select your region. In this case, we only have one available region.

DIC_Select_Region

Once you select that region, you are returned to the main page for adding a Dial-In Access number. Click “Commit” and you now have a Dial-In Access number.

For those excited by PowerShell, you can perform all of the above using the following PowerShell commands:

Set-CsDialPlan -Identity &quot;Global&quot; -DialInConferencingRegion &quot;United States&quot;
New-CsDialInConferencingAccessNumber -PrimaryUri &quot;sip:+13175551212@flinchbot.com&quot; -DisplayNumber &quot;(317) 555-1212&quot; -DisplayName &quot;Indianapolis&quot; -LineUri &quot;tel:+13175551212&quot; -Pool lyncpool.flinchbot.com -PrimaryLanguage &quot;en-US&quot; -Regions &quot;United States&quot;

So how can we see what this now looks like? Point a web browser to your dial-in simple URL. In my case, that is https://dialin.flinchbot.com and I see the following:

DialIn1

 

If you don’t know your dial-in Simple URL, you can run the following PowerShell command:

Get-CsSimpleUrlConfiguration

Now more has happened here beyond just having created a new dial in number for the United States.

[Here is the part I never really knew until this week…]

What I have also done is assigned a default dial-in number for all of my users. This may seem obvious but it really isn’t (at least to my thick Hoosier skull (or I guess my now Nashvillian skull)). The reason that all of my users now have a default dial in number is because I assigned the Region to the Global dial plan. I currently only have one dial plan so everyone gets this dial plan by default. Since the dial plan controls the region, all of my users are now considered to be in the United States region.

So what happens if I create a new dial plan. Does the global Region still define the Region for users assigned to a user-level (or site-level) dial plan? Let me create a user level dial plan without a region and see what happens.

Testing this gets a little tricky because we can’t just go to the dial-in simple URL because that just shows a list of all the defined numbers, not the default number for a given user. Since I created a user-level dial plan, I had to assign that dial plan to a specific user. In order for them to see what their dial-in Region is, they need to create an Outlook meeting and then use the Lync Meeting calendar add-in (alternately, a “Meet Now” meeting directly from the Lync client).

Doing all of those steps, I see that the Global dial-in Region applies if the user-level dial plan has no Region defined.

DIC_1

So it’s probably a good idea to set a default Region in your Global dial plan. Unless you don’t want everyone to have a default location. Then leave it blank.

Now let’s go to the next step. I want to add a second dial-in number for our office in Nashville. I will call this region “United States – Southeast”. I create a User-Level dial plan and simply type “United States – Southeast” into the “Dial-in conferencing region” field. I then skip over and create a new dial-in access number.

After waiting about 5 minutes I reloaded the dialin.flinchbot.com page and I see that I now have a new entry in my list.

DialIn2

So that’s pretty cool. But here’s the part that I just figured out this week:

How do we set the default dial-in number for a user when they create a new meeting invite via Lync? It is obvious now but for years I never really knew. I always told people to manually edit the settings in their Outlook Lync Meeting options tool.

 

Meeting Options 1

Meeting Options 2

Now setting that works fine for individual users. I was asked how this can be changed for an entire office and I…uh…well…uh…stammered an “I don’t know”.

Well now I know. And it’s really obvious to me. Now.

All you have to do is set the users dial plan to one that contains the correct region. Duh! So if I have a user who needs to use the “United States – Southeast” dial-in number as their default I then assign them to the user dial plan I created. If the user needs the generic “United States” as their default dial plan I leave their dial plan setting unassigned (i.e., the Global dial plan).

Here is what a meeting invite looks like after I changed my test user from the Global dial plan to the user-level dial plan:

dic 2

Notice that it now sets the default dial-in number to “United States – Southeast” instead of the Global “United States”.

To expand on this, if you have an office (or, more likely, a region) with 4 dial plans, you have to make sure that the Region on all 4 dial plans says the same thing. It’s a bit redundant to have to manually type in the same region value into each dial plan.

So use PowerShell!

Set-CsDialPlan -Identity &quot;Atlanta&quot; -DialInConferencingRegion &quot;United States - Southeast&quot;
Set-CsDialPlan -Identity &quot;Tampa&quot; -DialInConferencingRegion &quot;United States - Southeast&quot;
Set-CsDialPlan -Identity &quot;Orlando&quot; -DialInConferencingRegion &quot;United States - Southeast&quot;
Set-CsDialPlan -Identity &quot;Raleigh&quot; -DialInConferencingRegion &quot;United States - Southeast&quot;

Here is an advanced scenario you might run into. Let’s say that somehow you get a batch of dial-in conferencing numbers that you need to add to Lync, for example via SIP trunks that bring in a bunch of phone numbers from around the globe to a central location. How do you add those Regions?

The same as you would in any other scenario. You have to create a dial plan and type in the region name. In other words, you create “dummy” dial plans (if necessary), set the region in those dummy dial plans, and then use that region when defining the dial-in access number.

Here is some PowerShell showing how to create 3 “dummy” dial plans and three dial-in access numbers using the regions created in those “dummy” dial plans:

#Argentina
New-CsDialPlan -Identity &quot;DIC-Argentina&quot; -DialInConferencingRegion &quot;Argentina&quot;
New-CsDialInConferencingAccessNumber -PrimaryUri &quot;sip:DIC_Argentina@flinchbot.com&quot; -DisplayNumber &quot;+54123456789&quot; -DisplayName &quot;Argentina&quot; -LineUri &quot;tel:+54123456789&quot; -Pool lyncpool.flinchbot.com -PrimaryLanguage &quot;es-MX&quot; -SecondaryLanguage &quot;en-US&quot; -Regions &quot;Argentina&quot;

#Austria
New-CsDialPlan -Identity &quot;DIC-Austria&quot; -DialinConferencingRegion &quot;Austria&quot;
New-CsDialInConferencingAccessNumber -PrimaryUri &quot;sip:DIC_Austria@flinchbot.com&quot; -DisplayNumber &quot;+43123456789&quot; -DisplayName &quot;Austria&quot; -LineUri &quot;tel:+43123456789&quot; -Pool lyncpool.flinchbot.com -PrimaryLanguage &quot;de-DE&quot; -SecondaryLanguage &quot;en-GB&quot; -Regions &quot;Austria&quot;

#Bahrain
New-CsDialPlan -Identity &quot;DIC_Bahrain&quot; -DialinConferencingRegion &quot;Bahrain&quot;
New-CsDialInConferencingAccessNumber -PrimaryUri &quot;sip:DIC_Bahrain@flinchbot.com&quot; -DisplayNumber &quot;+973123456789&quot; -DisplayName &quot;Bahrain&quot; -LineUri &quot;tel:+973123456789&quot; -Pool lyncpool.flinchbot.com -PrimaryLanguage &quot;en-GB&quot; -Regions &quot;Bahrain&quot;

Note on the New-CsDialPlan I don’t do anything other than provide a name (identity) and set a region. That’s all. There is no need for anything else because this dial plan will never actually be used as a dial plan (i.e. phone number normalization). They are being created solely to define a region.

Now look at the dial in web page:

DialIn3

That looks like a real dial-in page now! Note that my test user, when creating a Lync meeting via Outlook will still use the “United States – Southeast” number as his default number as he is assigned to that dial plan. If I wanted him to use the Bahrain number as his default dial-in number is would have to move him to that dial plan (and probably add some normalizations too).


I think that about wraps it up. This is stuff I feel like I should have known years ago but for some reason it didn’t click until this past week. That’s probably due to me having to add about 25 SIP-delivered dial in numbers to our central pools and me actually having to think it all the way through.  I now feel bad to those people to whom I gave wrong, or at least mediocre, information about setting the default dial-in numbers.

For me, the big take away is that *every* dial plan should have a region set.

For more (and probably better) explanations, check here and here.

Lync Regions and assigning Dial-In Conference Numbers

I consider myself really sharp at Lync. However there are still times when I have “duh” moments that I feel like I should have known for years. Since Lync is a pretty complex and varied system there are just some things I never sat down and properly figured out. Dial-In conferencing Regions is one of them. I’ve probably set up dozens of dial-in conferencing numbers over the past few years but there were still a few things I just missed. This article will do a fairly deep dive into Regions and Dial-in Conferencing numbers.

So first off: What is a Region? A Region is anything you want it to be. It’s just some text. A region is independent of an Active Directory site or a Subnet or anything similar. A Region could be “Earth”. A Region could be “Germany”. A Region could be “My bedroom in the basement of mom’s house”. In practicality, a Region is used to define where a dial-in conferencing phone number resides. So if I have a dial in number in Indianapolis and one in Stockholm, the regions could be”Indianapolis” and “Stockholm” or they could be “United States” and “Sweden” or they could be “North America” and “Europe”. The Regions are just a way to let people know where the dial-in conferencing phone number is located.

None of this should be too mind blowing.

So where do you configure these region names? If you answer: “In the same place where you configured the dial-in conferencing number” then you would be wrong. You actually configure them in Dial Plans. There is a reason for this that I will get to later.

In order to set a region, open any dial plan and in the “Dial-in Conferencing Region” box, type in anything you want. In the example below, I entered United States. Also note that this is being set on the “Global” dial plan.

If we want to see our existing dial-in conferencing Regions, you can run this PowerShell command:

Get-CsDialPlan | Select-Object DialInConferencingRegion

If I run that command I see the following:

OK this is great. I have a region. Now how do I assign it to a Dial-In Conference number?

Assuming you don’t have one yet, let me show you quickly how to create a dial-in conferencing number. In Lync Control Panel, navigate to the “Conferencing” section and then the “Dial-in Access Number” tab. Click “New”

Look at the above image. The “Display Number” can be anything you want. It can be in any format you want. In this case I formatted it to the standard way phone numbers in the North America Numbering Plan tend to be formatted. The Display Name field is really a comment for you the administrator so you know why this number was added. Line URI must be the exact, normalized phone number that Lync will use to answer the call. This number needs to be exactly right. The SIP URI can be anything you want. I often make it match the Line URI but you can use anything you want. The Pool is used to tell Lync which of your Lync pools will receive the inbound call. Finally you can select a Primary language and up to four secondary languages for this dial-in access number.

And where do we define the Region? All the way down at the bottom. I have to scroll down so you can see it.

After clicking the Add button you are given a list in which to select your region. In this case, we only have one available region.

Once you select that region, you are returned to the main page for adding a Dial-In Access number. Click “Commit” and you now have a Dial-In Access number.

For those excited by PowerShell, you can perform all of the above using the following PowerShell commands:

Set-CsDialPlan -Identity "Global" -DialInConferencingRegion "United States"
New-CsDialInConferencingAccessNumber -PrimaryUri "sip:+13175551212@flinchbot.com" -DisplayNumber "(317) 555-1212" -DisplayName "Indianapolis" -LineUri "tel:+13175551212" -Pool lyncpool.flinchbot.com -PrimaryLanguage "en-US" -Regions "United States"

So how can we see what this now looks like? Point a web browser to your dial-in simple URL. In my case, that is https://dialin.flinchbot.com and I see the following:

 

If you don’t know your dial-in Simple URL, you can run the following PowerShell command:

Get-CsSimpleUrlConfiguration

Now more has happened here beyond just having created a new dial in number for the United States.

[Here is the part I never really knew until this week…]

What I have also done is assigned a default dial-in number for all of my users. This may seem obvious but it really isn’t (at least to my thick Hoosier skull (or I guess my now Nashvillian skull)). The reason that all of my users now have a default dial in number is because I assigned the Region to the Global dial plan. I currently only have one dial plan so everyone gets this dial plan by default. Since the dial plan controls the region, all of my users are now considered to be in the United States region.

So what happens if I create a new dial plan. Does the global Region still define the Region for users assigned to a user-level (or site-level) dial plan? Let me create a user level dial plan without a region and see what happens.

Testing this gets a little tricky because we can’t just go to the dial-in simple URL because that just shows a list of all the defined numbers, not the default number for a given user. Since I created a user-level dial plan, I had to assign that dial plan to a specific user. In order for them to see what their dial-in Region is, they need to create an Outlook meeting and then use the Lync Meeting calendar add-in (alternately, a “Meet Now” meeting directly from the Lync client).

Doing all of those steps, I see that the Global dial-in Region applies if the user-level dial plan has no Region defined.

So it’s probably a good idea to set a default Region in your Global dial plan. Unless you don’t want everyone to have a default location. Then leave it blank.

Now let’s go to the next step. I want to add a second dial-in number for our office in Nashville. I will call this region “United States – Southeast”. I create a User-Level dial plan and simply type “United States – Southeast” into the “Dial-in conferencing region” field. I then skip over and create a new dial-in access number.

After waiting about 5 minutes I reloaded the dialin.flinchbot.com page and I see that I now have a new entry in my list.

So that’s pretty cool. But here’s the part that I just figured out this week:

How do we set the default dial-in number for a user when they create a new meeting invite via Lync? It is obvious now but for years I never really knew. I always told people to manually edit the settings in their Outlook Lync Meeting options tool.

 

Meeting Options 1

Meeting Options 2

Now setting that works fine for individual users. I was asked how this can be changed for an entire office and I…uh…well…uh…stammered an “I don’t know”.

Well now I know. And it’s really obvious to me. Now.

All you have to do is set the users dial plan to one that contains the correct region. Duh! So if I have a user who needs to use the “United States – Southeast” dial-in number as their default I then assign them to the user dial plan I created. If the user needs the generic “United States” as their default dial plan I leave their dial plan setting unassigned (i.e., the Global dial plan).

Here is what a meeting invite looks like after I changed my test user from the Global dial plan to the user-level dial plan:

dic 2

Notice that it now sets the default dial-in number to “United States – Southeast” instead of the Global “United States”.

To expand on this, if you have an office (or, more likely, a region) with 4 dial plans, you have to make sure that the Region on all 4 dial plans says the same thing. It’s a bit redundant to have to manually type in the same region value into each dial plan.

So use PowerShell!

Set-CsDialPlan -Identity "Atlanta" -DialInConferencingRegion "United States - Southeast"
Set-CsDialPlan -Identity "Tampa" -DialInConferencingRegion "United States - Southeast"
Set-CsDialPlan -Identity "Orlando" -DialInConferencingRegion "United States - Southeast"
Set-CsDialPlan -Identity "Raleigh" -DialInConferencingRegion "United States - Southeast"

Here is an advanced scenario you might run into. Let’s say that somehow you get a batch of dial-in conferencing numbers that you need to add to Lync, for example via SIP trunks that bring in a bunch of phone numbers from around the globe to a central location. How do you add those Regions?

The same as you would in any other scenario. You have to create a dial plan and type in the region name. In other words, you create “dummy” dial plans (if necessary), set the region in those dummy dial plans, and then use that region when defining the dial-in access number.

Here is some PowerShell showing how to create 3 “dummy” dial plans and three dial-in access numbers using the regions created in those “dummy” dial plans:

#Argentina
New-CsDialPlan -Identity "DIC-Argentina" -DialInConferencingRegion "Argentina"
New-CsDialInConferencingAccessNumber -PrimaryUri "sip:DIC_Argentina@flinchbot.com" -DisplayNumber "+54123456789" -DisplayName "Argentina" -LineUri "tel:+54123456789" -Pool lyncpool.flinchbot.com -PrimaryLanguage "es-MX" -SecondaryLanguage "en-US" -Regions "Argentina"

#Austria
New-CsDialPlan -Identity "DIC-Austria" -DialinConferencingRegion "Austria"
New-CsDialInConferencingAccessNumber -PrimaryUri "sip:DIC_Austria@flinchbot.com" -DisplayNumber "+43123456789" -DisplayName "Austria" -LineUri "tel:+43123456789" -Pool lyncpool.flinchbot.com -PrimaryLanguage "de-DE" -SecondaryLanguage "en-GB" -Regions "Austria"

#Bahrain
New-CsDialPlan -Identity "DIC_Bahrain" -DialinConferencingRegion "Bahrain"
New-CsDialInConferencingAccessNumber -PrimaryUri "sip:DIC_Bahrain@flinchbot.com" -DisplayNumber "+973123456789" -DisplayName "Bahrain" -LineUri "tel:+973123456789" -Pool lyncpool.flinchbot.com -PrimaryLanguage "en-GB" -Regions "Bahrain"

Note on the New-CsDialPlan I don’t do anything other than provide a name (identity) and set a region. That’s all. There is no need for anything else because this dial plan will never actually be used as a dial plan (i.e. phone number normalization). They are being created solely to define a region.

Now look at the dial in web page:

DialIn3

That looks like a real dial-in page now! Note that my test user, when creating a Lync meeting via Outlook will still use the “United States – Southeast” number as his default number as he is assigned to that dial plan. If I wanted him to use the Bahrain number as his default dial-in number I would have to move him to that dial plan (and probably add some normalizations too).


I think that about wraps it up. This is stuff I feel like I should have known years ago but for some reason it didn’t click until this past week. That’s probably due to me having to add about 25 SIP-delivered dial in numbers to our central pools and me actually having to think it all the way through.  I now feel bad to those people to whom I gave wrong, or at least mediocre, information about setting the default dial-in numbers.

For me, the big take away is that *every* dial plan should have a region set.

For more (and probably better) explanations, check here and here.