Would it be nice to list all leakedcredentials using powershell?(or riskysignins or identiyriskevents). All of this could be achieved using powershell and REST api at Microsoft Graph. I have a scheduled task running to get this reports. Using a appilcation in Azure. All credentials are stored in SecretServer. First we need an Application Registration in Azure.
After we have created the AppReg. Add a password, app key. Combined with the application id this is our username and password.
Now it is time to give this app the required permissions from microsoft we can identify witch permissions are needed to run this query. https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/leakedcredentialsriskevent_get
Next would be to set the enterprise application to “user assignment required” and “Enabled for users to sign-in.” also “Hide it from users.
Now we are ready to start with our powershell script.
To see information stored in SfB addresslist you can dump its content to a text file:
C:\Program Files\Skype for Business Server 2015\Server\Core>abserver -dumpfile “\\\1-WebServices-1\ABFiles\00000000-0000-0000-00 00-000000000000\00000000-0000-0000-0000-000000000000\f-195a.lsabs” c:\temp\sdump.txt
Ran into a issue where Skype for Business frontend service refused to start. It remained in starting for ages before giving up. In the event viewer the statement was : Server startup is being delayed because fabric pool manager is initializing. This event seemed to have something to do regarding pool, but this was a standardedition Skype for Business setup containing one frontend and one edge server.
Many articles on Bing and Google explained how this could be a issue with the certificates on the server, but in our case the frontend server and edge server was happily replicating the topology. We started by trying to do as the event told us:
But this also failed. For me it looked like there was something wrong with WindowsFabric. Compared with another SfB server and in taskmanager I could see fabric.exe running, but not on on the server with the issue. Looking in eventviewer Microsoft/WindowsFabric Admin:
At first I tried to install Windows Fabric from SfB install media. But same error. Then we tried to uninstall and reinstall. This resulted in a more serious error. Now the server has lost its connections to the Fabric. So how do we fix this. My solution was to uninstall SfB frontend server module and then run the Deployment wizard to reinstall it with config from the management store. This worked perfect. The front end service started immediately.
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.