Ignite 2015: Call for Topics

ignite ButtonIn October, I reported on the new ‘mother of all Microsoft events’, Microsoft Ignite. This event is going to take place from May 4-8, 2015 in Chicago, US.

Contrary to how the agenda used to be determined for events like TechEd or the Microsoft Exchange Conference (MEC), Microsoft is now asking for your help by scoring contents and topics. By completing a short, anonymous Call for Topics survey here, you can let those in charge of assigning session slots know what you would like to see at Ignite.

If you have any questions on Ignite, Microsoft is also having some Twitter sessions for specific products. More on this in the original Call for Topics post here. The Exchange session takes place at Tuesday, December 2nd 9 am (Pacific Time) and use hashtag #ignitejam to participate.

So, if you went to MEC and would like to see a fair share of Exchange or Office 365 should you visit Ignite, be sure to complete the Call for Topics survey and plug your favorite product or platform.

The UC Architects Podcast Ep44

iTunes-Podcast-logo[1]Episode 44 of The UC Architects podcast is now available,which was recorded at the Norwegian Lync Day. This episode is hosted by Pat Richard, who joined by Ståle Hansen, Tom Arbuthnot and Steve Goodman. Special guests are Lasse Nordvik WedøAdam GentJohan Delimon, Tommy Clarke, and Martin Lidholm. Editing was done by Andrew Price.

Some of the topics discussed in this episode are:

  • Configuring QoS for Lync IP Phones
  • New version of Lync SDN interface
  • Lync Call Concurrency Calculator
  • Never be late for a meeting again
  • MS14-055 Broke My Edge Server
  • Norwegian Lync Day recap
  • Session recap: Lync Backup and Restore by Lasse Nordvik Wedø
  • Session recap: Lync Hybrid and Skype by Tommy Clarke
  • Session recap: Lync Mobile sign in process and media flow by Tom Arbuthnot
  • Session recap: SIP and media in Lync explained by Johan Delimon
  • Session recap: Lync voice explained by Adam Gent
  • Lessons learned about holding a conference by Ståle Hansen
  • Session recap: 5 Elements That Ensure a Successful Lync Deployment by Martin Lidholm
  • TechEd Europe events

More information on the podcast including references and a link to download the podcast here or you can subscribe to the podcasts using iTunes, Zune or use the RSS feed.

About
The UC Architects is a bi-weekly community podcast by people with a passion for Unified Communications; our main focus is on Exchange, Lync or related subjects.

Aaand we named it .. Microsoft Ignite!

Today Microsoft revealed the name of the event temporarily known as MUTEE, or Microsoft’s Unified Technology Event for Enterprises:

Microsoft Ignite 2015 Full

The Microsoft Ignite event, which replaces Microsoft Exchange Conference, LyncConf, Microsoft Management Summit, SharePoint Conference and TechEd North America, will be held from May 4-8, 2015 in Chicago at McCormick Place. On the Exchange Team blog, former  Microsoft Exchange Conference attendees are told this will be their ‘go to’ event for 2015 (apart from independent conferences, such as Exchange Connections 2015).

The Microsoft Ignite 2015 site is already up and you can even register, in case you are worried this event with a potential of 20k attendees will soon be sold out. Microsoft is asking potential attendees to provide input through a YamJam. For those unenlightened, a YamJam is a virtual event on Microsoft’s Enterprise Social platform called Yammer, meaning you have to register on the hosting Yammer network first.

The announcement on the Office blog has some additional information here, including information on Convergence and //Build 2015.

PS: It is likely that the adoption of this name has consequences for the events formerly known as Ignite, e.g. Office 365 Ignite. Those events were technical training to get IT Pros up to speed on new products. The faith of those training sessions has not been disclosed.

The UC Architects Podcast Ep43

iTunes-Podcast-logo[1]Episode 43 of The UC Architects podcast is now available, which is hosted by Pat Richard. Pat is joined by Steve Goodman, Johan Veldhuis, Serkan Varoglu, and yours truly. Editing was done by Andrew Price.

Some of the topics discussed in this episode are:

  • Unable moving mailboxes to Exchange 2013 DB excluded from provisioning
  • Protecting against Rogue Administrators
  • Combine Office 365 tenants after a merger or acquisition
  • Hybrid,EAC,Ex2007 & In-Place Hold issues in Ex2013 CU6 & OWA bug
  • Certain pages or windows don’t appear in Outlook Web App or in the Exchange admin center when using Google Chrome
  • Using PowerShell Background Jobs can help you speed up Exchange Tasks
  • Script: Invoke-snomControl PowerShell GUI
  • Microsoft Removes September’s Lync Vulnerability Update Due to Problems
  • Lync Room System Cumulative Update (Sep2014)
  • Lync Phone Edition (LPE) Log Viewer
  • September 2014 update for Lync 2013 client
  • Script:PolycomVVX FTP Provisioning Server Creation Script
  • SecureOfficeWebApps Farm with “FarmOU” Setting
  • High CPU after Publishing Lync Topology
  • Microsoft Office for Mac 2011 14.4.4 update
  • Lync Mobile update–Gallery View on iPad and participant management on both iPad and iPhone
  • IT/Dev Connections (wrap-up)
  • TechEd Australia
  • Norwegian Lync Day
  • UC Birmingham User Group

More information on the podcast including references and a link to download the podcast here or you can subscribe to the podcasts using iTunes, Zune or use the RSS feed.

About
The UC Architects is a bi-weekly community podcast by people with a passion for Unified Communications; our main focus is on Exchange, Lync or related subjects.

The UC Architects Podcast Ep42

iTunes-Podcast-logo[1]Episode 42 of The UC Architects podcast is now available, which is hosted by Pat Richard, who is joined by John A. Cook, Tom Arbuthnot and yours truly. Editing was done by Andrew Price.

Some of the topics discussed in this episode are:

  • Tool: PelNet v2.0
  • Managed Availability Probes
  • Skype for Desktop Settings – Set-SkypeClientPreferences withPowerShell
  • New firmware for LPE devices
  • Desktop sharing update
  • New Tool: Lync Common Area Phone Management (GUI)
  • Lync SDN For Dummies
  • Lync Anonymous Response Group Limitations and Field Notes
  • Practical use of Call Quality Methodology
  • New Tool: Event Zero Broadcast IM tool
  • Lync Server 2013 Cumulative Update (flex fabric update)
  • Static route for Edge server internal interfaces
  • UC Architects @ Connections speakers and Scheduled Maintenance party
  • Norwegian Lync Day
  • TechEd Europe 2014
  • Northern UC User Group

More information on the podcast including references and a link to download the podcast here or you can subscribe to the podcasts using iTunes, Zune or use the RSS feed.

About
The UC Architects is a bi-weekly community podcast by people with a passion for Unified Communications; our main focus is on Exchange, Lync or related subjects.

Exchange UM and Lync issue using wildcard certificate

Recently, after installing and configuring Lync in an Exchange environment, a customer had issues like not being notified of voice-mail messages (also known as MWI or Message Waiting Indicator) and things like play-on-phone wasn’t working properly. To configure Exchange UM and Lync integration, the customer used the ExchUCUtil.ps1 script on Exchange and OCSUMUtil.exe tool on Lync. They also applied a valid, not-self signed certificate for Exchange UM services, as stated in the official instructions here.

Attendants and Subscriber Access was functioning properly, as well as call diversion to voicemail. Also, people were able to retrieve and replay voicemail messages.

So, apparently communications originating from Lync to Exchange was working, but from Exchange to Lync wasn’t.

I started off by inspecting the eventlog on the Exchange Server. Here I noticed UMCore process generated event 1400 periodically when trying to contact the UM IP gateway (Lync server):

TimedOut@ExchangeUM

This provided a clue as to what I already expected; the Lync server wasn’t responding to Exchange.

A quick search led me to this blog, which is mainly a checklist. Since Lync and Exchange were able to set up an RPC session and after verifying the ability to communicate from Exchange to Lync by doing a telnet on port 5061, I concluded networking wasn’t the issue and required services seemed to be running properly.

Next, I increased the logging level for all UM related components using:

Get-EventLogLevel “MSExchange Unified Messaging\*” | Set-EventLogLevel –Level Expert

I created a new voicemail message and after a short while MWI General event 1344 showed up:

MWIFail@ExchangeUM

Again, an indication signaling from Exchange to Lync didn’t work. Because I was able to open communications on port 5061 earlier on, I suspected Lync might be rejecting or refusing communications for whatever reason. Therefor, I connected to the Lync server. Since no clues were found in the event  log, I fired up the Lync Server Logging Tool. I turned on logging for SIPStack, checked All Levels and All Flags and started logging. Since I didn’t want to wait for the UM contacting Lync cycle and because it was a live system so a lot of SIP traffic was expected, I quickly created another voicemail waited a while (for accommodate for Voicemail Preview generation) and stopped logging. Next, I selected Analyze Log Files to inspect the results.

Note: Analyze Log Files requires installing the Lync Resource Kit as utilizes the Snooper tool; hardcore SIP fanatics may prefer the Notepad view and click on View Log Files instead.

When going through the events I noticed the following dialog between the Exchange server (srv12) and Lync (srv03):

ErrorMsg@LyncLogger

After establishing a TLS session (so SIP secured was configured properly on both sides), the Lync Server received a SIP OPTIONS request after which it actively terminated the connection returning “The peer is not a configured server on this network interface” . The details section of this message displayed the following:

ErrorMsg@LyncLogger - Details

Now I have obfuscated the remainder of the FQDN, but as you probably still can see is that it states a wildcard as FQDN, e.g. *.contoso.com. Since “*.<something” isn’t a valid FQDN, Lync server wasn’t too blame for rejecting communications. I went back to the Exchange server because I suspected it might be a certificate issue and because I learned that the FQDN shown was the subject (CN) of the wildcard certificate used (and wildcard certificates aren’t supported by Lync).

I opened up the Exchange Management Console, went to Server Configuration to view the certificates. Indeed the public wildcard certificate was used for UM services. Luckily there was already another internal certificate in-place for Exchange,with the host FQDN as subject. I selected it, opened up Assign Services and activated it for UM (which automatically disables UM for the other certificate).

CfgUMCert@ExchangeUM

After switching certificates for UM, UM services like MWI and play-on-phone started working properly.

Apparently, the instructions “If you didn’t choose to create a wildcard certificate .. you must use a public certificate if you are using Unified Messaging with Office Communications Server” isn’t complete, since Lync verifies the certificate’s subject against the FQDN of the host it’s talking to. So that rules out certificates with a wildcard Subject (CN). Unfortunately, the certificate creation instructions don’t rule out (public) wildcard certificates for UM and there’s no mention of limitations regarding the Subject. I assume originally the customer created an improper – yet technically valid – request for an “all in one” certificate for internal usage and applied the result to all Exchange and Lync services, breaking UM – but not IIS nor SMTP, in the process.

Update: Turns out the requirement for non-wildcard subjects in certificates subject names is mentioned in the Supportability section of the Lync documentation on TechNet here. It reads: “There is no support for a wildcard entry as the subject name (also referred to as the common name or CN) for any role”.  Using wildcards as one of the Subject Alternate Names (SAN) is supported for most Lync roles. Since a lot of people find certificates challenging and troubleshooting improperly configured certificates isn’t everyone’s favorite pastime, being as clear as possible helps a lot. In my opinion, the certificate generation page should mention limitations or requirements and a link to the supportability page wouldn’t hurt. Luckily, in this case the issue can easily be solved using a trusted certificate generated by an internal CA.