Have done several upgrades from Lync 2013 to Skype for Business 2015, so this last one should be no different, but faith had other plans.
Installed topology builder on a new computer and prepared the upgrade process. But when a bit into the upgrade it failed.
Error: Error returned while installing OcsCore.msi(Feature_LocalMgmtStore), code 1603. Error Message: A fatal error occurred during installation. For more details please consult log at C:\Users\paupav\AppData\Local\Temp\Add-OcsCore.msi-Feature_LocalMgmtStore-[2018_10_17][14_05_11].log
As most people know a MSI error of 1603 tells us as much as “An error occurred”. Tried do some reboots and retried, but nothing helped. With no idea of what could possibly be wrong, I was browsing for ideas or hints the usual places: Eventviewer, Windows explorer (free diskspace, files and folders), services, policies, and finally windows update settings and history. One clue (except that is was error 1603) there was 1 SfB update installed (probably because I selected the installer to check for updates). Thougt it was strange that there should be one update since I has not yet managed to install any SfB software.
So simple. Uninstalled the update , rebooted and the upgrade from now on went flawless.
This event started to appear every 20 seconds or so. The Skype for Business servers had recently been patched. In the patch list was updates to .Net framework. Included in these patches is a security update that resolves an security bypass feature. https://support.microsoft.com/en-us/help/4014510/description-of-the-security-and-quality-rollup-for-the-net-framework-4 . To solve this all I had to do was add the required registry key : HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\v4.0.30319 – DWORD: RequireCertificateEKUs=0 and restart the “Skype for Business Server Web Conferencing” service. The fix can be applied to Lync server 2013 as well.
Are your planning to use SAP on you DirectAccess enabled clients?
Please consider doing this:
Make sure your SAP GUI client version is 7.20
Set Systen Environment Variable on client pc: SAP_IPv6_ACTIVE to value 1
Reboot client PC.
This is what I had to do to get it to work! 🙂
Was installing a Skype for Business server the other day, and the simple task of preparing the forest failed. I am always on the alert when doing Active Directory forest wide tasks as prepare schema and prepare forest, so it is not fun to see error messages during these tasks.
What now. It is no good feeling to see “Unrecoverable” and “You cannot retry this operation”. But I had to retry, and then there was a slight different error message.
I’ve had errors before, and at those cases the simple thing to do was to change from “Local domain” to “Domain FQDN” in the “Universal Group Location” dialog box.
This time there was nothing but lots of scary errors.
I know this domain has several trusts configured, so it looks like the wizard get confused of where to put these groups. Next step was to run prepare forest from PowerShell so that I was able to provide all this information to the command.
Some users was missing in Office 365 Skype admin center. I verified that they had a Skype license plan assigned. Tried to remove and readd – did not help. These users are replicated from on premise to cloud using Azure AD sync. Turned out these users had previously been Lync enabled on on premise Lync server. Compared all ActiveDirectory attributes, and the only one that make any sense was msRTCSIP-DeploymentLocator.
The attribute did not have any value that I reacted to when I first saw it, But I cleared the value and ran a sync to O365.
Cleared it by opening the Attribute and pressed Clear button.
After the sync to Azure the user finally appeared in O365 Skype Admin Center.
One common question from users are “How can I forward my email to my home mail?” or from a manager “How can we forward his/her mail to the external address?”. In fact in Exchange there is several possibilities, but most of them requires some administrator involvement. For users to forward their own email an administrator would have to allow it.
Users could define a forward using outlook. This requre the administartor to allow it. The administrator will have to set “AutoForwardEnabled” on “Remote Domain” : Set-remotedomain “*” -AutoForwardEnabled $true . This will ofcourse enable this for all users. They will be enables to send to det remote domain defined or all.
As an administrator you could create an exchange contact and sett this as forwarding on the mailbox in the EMC. Mailbox properties and mailbox features -> Mail flow ->delivery options:
Here you can select an allready created Mail contact.
It can also be done from PowerShell, here you have one more option.Her we can specify either a contact or a smtp address, but you can not use both at the same time.
This will sett forwarding for mailbox with alias demouser to firstname.lastname@example.org , and also deliver mail to both the forwarding address and the mailbox. One thing to notice is that for this to work you will have to add “dom.ex” as a remote domain in exchange.
After we installed office 365 on our pc’s we discovered high disk IO, especially on our terminal servers. Running tools from sysinternals this turned out to be something in Office installation called Telemetry, When we started office apps some file, in the profile folder structure, called OTELE was constantly updated. Not one file, but several.
After som time of investigation we found one registry key that seem interesting “DisableTelemetry”. The obvious thing to do was to set this value to 1 (binary enabled). But that did not help at all. When we started Oulook the value was set to “0”. Searching the internet gave us the answer from Microsoft (second hand 🙂 ) That this could not be disabled. But after a support case : It would have taken us forever to find the value. The answer is 170000 ,
Set the value to 170000 and all disk IO to OTelemetry stopped. Now our servers are back to normal, only a subset of files are created.Thanks to Jan Ove Aarnes for his findings.
This is a rather confusing event. It occurs on the Exchange server 2010 that is holding the Unified Messaging role. “The following UM IP gateways did not respond as expected to a SIP OPTIONS request”, and at the end “This operation has timed out”. The server mentioned in the erro is, in this senario, the Lync server.
I thought I knew this PKI stuff and I was sure that all my certificates where correct. Also when telneting for the exchange server to the Lync server on port 5061 there was most defiantly an answer – No timeout”. After a while a decided to do all my certificates all over. Replacing the Lync , of course made no difference. When replacing the exchange certificate I change the SN to be the FQDN of the server, This did the trick. The error message disappeared. So now I remember that on Exchange UM server keep FQDN as Subject name and place all other names as SAN’s