Martin Gibney - Microsoft Teams

So another issue I came across with a Migration from Exchange 2007 to 2013 was that some clients were unable to open Outlook after being migrated to 2013. Error:  Cannot open your default e-mail folders. Microsoft Exchange is not available. This is quite a generic error and can be hard to troubleshoot. The issue I had was this was inconsistent and some users worked fine. Even when I added Full Access Permissions to the account on an account that was working, the mailbox opened fine. So on a hunch (and plenty of googling) I checked the casmailbox properties of the mailbox. Get-CASMailbox “user” | fl  This revealed that the property  MAPIBlockOutlookRpcHttp was set to True . So basically the user was blocked from connecting to Exchange using HTTP protocol, but HTTP is the only supported protocol in Exchange 2013. So we ran the following command to change this: Set-CasMailbox “user” -MAPIBlockOutlookRpcHttp $False Now Outlook opens just fine! We can change this setting

  Another common issue with Exchange and Outlook is that end users see pop ups complaining about the name on the certificate not matching the cert itself. " The name on the security certificate is invalid or does not match the name on the site " Or " The security certificate has a valid name " is marked with a red X   This tends to happen when the InternalURL does not match the certificate names. What this means in plain English is that the server name is either not on the certificate or does not match up. In many cases the servers will be built and use a single public wildcard certificate, however this wildcard certificate domain does not match the internal domain name. E.g. Mydomain.ie is the public SMTP name and wildcard cert *. mydomain.ie but the Active Directory domain is mydomain.local . We can "trick" the Exchange System into thinking that it is mydomain.ie and respond as such (No need to change domain n

So here is another issue I have come across twice this week alone. When setting up the TCP 5061 rules on firewalls between DMZ Internal and LAN on Checkpoint Firewalls, the default SIP rule being chosen by admins is SIP_TLS_AUTHENTICATION. However while a simple telnet will work between the servers (it may take 7-8 seconds extra) and it will look like it works but no logs in the Logger or errors about certificates. What I found is that if you change the rule to SIP_TLS_NOT_INSPECTED this resolved the issue. We could then see traffic coming completely through. Here is some information from checkpoint directly: Source: https://sc1.checkpoint.com/documents/R76/CP_R76_VoIP_WebAdmin/87769.htm

In advance of any installation of Lync products, ensure networking and firewall rules have been set up in advance. To save time during the install phase, you can ask the on site administrator to run the following: To assist in checking this is in place you can run the following tool ( https://www.allscoop.com/tcp-listen.php ) on the server and run my script ( http://ucireland.blogspot.ie/2015/05/testing-lync-2013-ports.html ) the opposing server. On the Edge Server listen on ports and test from LAN: 5061 TCP 4443 TCP 4443 TCP 8080 TCP 8057 TCP 5062 TCP 3478 UDP 443 TCP 50001 TCP 50002 TCP 50003 TCP 23456 TCP On the Front End Server listen on ports and test from DMZ: 5061 TCP On the Edge Server listen on ports and test from INTERNET: 443

I have written the following PowerShell scripts based on the great work of Original Author: Boe Prox   (https://boeprox.wordpress.org). The scripts simply check and report on all required ports between Front End, Edge Server and Reverse Proxy. Each script should be run on the corresponding server: From Front End TO Edge From Edge TO Front End From Reverse Proxy TO Front End I hope these are 1/2 as useful to you as they are to me :)

Very simply: Front End & Edge Servers **********************  Windows PowerShell 3.0 (is installed by default)  Microsoft .NET Framework 4.5 ( http://go.microsoft.com/fwlink/p/?LinkId=268529 )  Windows Identity Foundation 3.5 (part of script below) 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, Telnet-Client, BITS, Desktop-Experience, Windows-Identity-Foundation -Source D:\sources\sxs

A common issue I come across is that the Lync Front End does not replicate with the Edge server. When you run the command "Get-CsManagementStoreReplicationStatus" you see that FALSE is shown for the edge server and no dates are shown for last replication or status. 1. Check that port 4443 is open in each direction (you can use my script to check these ports) 2. Check you can reach the URL https://edgeinternalfqdn.domain.ie:4443/Replicationwebservice URL and are presented with the correct page. 3. If you are running Windows 2012 R2 on the edge check that you do not have more than 200 Certificates in any of the stores on Local Computer store. 4. Add the following .reg file to the edge server and restart the server (This is an important step), this is the usual fix in my opinion. Copy the below into a .reg file and run: **** Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "ClientA

So for some reason there are no default policies created in Lync for Conferencing. I have created a few easy cmdlets which will create a Standard, Enterprise and Enterprise Plus Conference policies. These will keep your users within their CAL licensing. You can tweak them where required in relation to sharing/recording. Just remember that Standard CAL users cannot share desktop or start multi-party (3 or more) conferences/calls..... I always set the global policy to the Standard CAL licensing to ensure nothing is missed. Hope this saves you some hassle... # The command below changs the default Global Policy to be set to Standard features to ensure any users on Global policy are set to STD Set-CsConferencingPolicy –Identity “Global” –AllowIPAudio $false -AllowIPVideo $false -Description "Standard CAL Client Policy" -AllowParticipantControl $true -AllowAnnotations $true -AllowUserToScheduleMeetingsWithAppSharing $False -AllowAnonymousUsersToDialO

So now that Windows Update pushes the Skype For Business client to machines your users will now see the following message once updated: Once restarted the user will continue to use the Lync client albeit with a Skype Icon now. Searching for Lync in Windows 7/8/10 will also bring up the Skype client in the results. Some users wish to use the Skype client now (god knows why, its not pretty) and here is how you can go about doing this. Method 1 - Policy from Lync server Lync admins can run the following commands on the Lync Server Management Shell: Set-CsClientPolicy -Identity Global -EnableSkypeUI $true New-CsClientPolicy -Identity SalesClientUI -EnableSkypeUI $true With the second option above being to create a new policy which you can assign per user. Option 2 - Manually on the Client Registry If you have trouble with some clients, you can always update their registry manually: Field Value to select or enter Action Create Hive HKEY_CURRENT

Ok, So while I was getting back into doing actual blogs I figured I needed to insert Powershell script into my blogs. The easiest way of doing this is by using an add-on for the Windows Powershell ISE editor. In its easiest form do the following: 1. Download this following file and extract. 2. Open Powershell as an Administrator and run the following: Set-ExecutionPolicy RemoteSigned 3. Run the setup.exe from the download. 4. Now in Powershell ISE editor, highlight all the code you want, click on Add-Ons at the top menu, then click Copy as HTML. Now simply paste as HTML into your blog! Enjoy. Martin

I created this script as the need to set up the same rules (as a whole) exist in many of the projects I work on. These rules can obviously be changed but should form the basis for your own personalised script. I have put in as many comments as I think are needed so it should guide you well. These are specifically for Ireland as we use a different format for some numbers. For example freephone numbers in most countries are 0800 but in Ireland it is 1800 which means normalising this is not an easy task! The script below assumes calls are being sent to a PSTN Gateway via a SIP trunk. Martin ################# #         # #    BEFORE     # #    YOU BEGIN # #         # ################# # Get the PSTN Gateway ID as you will need this later # Get-CsService -PSTNGateway -- Change this on "VOICE ROUTES" section # Assumes Gateway is already set up. # ################# #         # #    DIAL     # #    PLAN     # #         # ##########