Having information about how Teams app is running is important, so this quick post will overview how a snapshot collection of important diagnostic logs for troubleshooting can be done
Important tips!
Once you have enabled the diagnostic logs, those will be created in the downloads folder:
Hope that helps to troubleshoot your Teams deployment!
This history began with a new dev project, we needed to be included in a DevOps Project inside the customer organization.
We were first invited to the Teams group to collaborate, upload the documentation and so on, so our users were first created in the AAD of the customer, till here, no problem.
But then, the customer created the DevOps project, and he invited us to collaborate in the project, we received the mail, but when we tried to access, we were receiving the following error message:
We were pretty sure, that we had access to the project, we were checking with the customer the access, and we were having access, we waited some time to replicate the permissions change, but nothing, so where was the problem?
The error page shows that we do not have access, so after digging a while with the problem, I realized that when I tried to navigate to the organization URL, in Edge was showing the error message that could lead us to something:
So, the problem is that guests are not allowed to access to the organization (TF909091), so how we can solve that problem?
Pretty simple, we need to ask the customer, to go to the organization settings and modify the security policies:
Also, to check if in the policies of the project, the check was allowed:
After doing that, we were able to access to the DevOps project, and start working
Problem and mystery solved!
This is a reminder to myself, long time ago I needed to configure an ADConnect service, since today. I used other account to configure the service, but when I tried to access to the server with another account I was receiving the follwing error:
Unable to connect to the Synchronization Service.
Some possible reasons are:
See the Synchronization Service documentation for details
Solution:
Check if the Microsoft Azure AD Sync Service is started
Check is your account is a member of the local ADSyncAdmins and/or ADSyncOperators group,if not, add the current user to this group and logoff and logon again !
In a project where WVD was involved, we needed to implement AADDS and FSlogix to the scenario. If you take a look to that scenario, it is pretty simple, but it hides some stones that we hit during the road, so I want to explain them in this post 😊
First of all, once you have deployed the AADDS, remember to check DNS settings in the VNet, it is necessary to put the DNS from the AADDS, otherwise won’t be possible to join VMs to the AADDS domain:
Once the AADDS instance was deployed it took turn for the golden image, as you probably know there is no problem to install all the programs and updates, but our stone here was once we deployed the language pack and the image was prepared, the sysprep was crashing, so we need to deep dive into the logs to solve the problem…
So the deployment begun to be fun, but after digging, we were able to solve by executing…
Remove-AppxPackage -Package Microsoft.LanguageExperiencePackes-ES_19041.17.51.0_neutral__8wekyb3d8bbwe -AllUsers
And then… boom!
Probably you will need to change your package in your case but is important to include the -allusers parameter.
Solved the golden image problem, it take turn to the deploy the host pool which process was straightforward. Our next stone was the storage account… ☹
Deploying the storage account into the AADDS was easy, but the problem was to give NTFS permission to the users, we were used to do that process in ADDS scenarios, so we know what to do, but with AADDS the procedure changes a bit…
So my piece of advice, would be to follow the instructions given in docs: Uso de Azure AD Domain Services para autorizar el acceso a los datos de archivo a través de SMB | Microsoft Docs
We were using the AAD credentials and we were stuck for a while until we read this in the documentation. Lesson learned, read documentation help.
Once you have entered to the storage account with your storage account key, you are able to give NTFS permission to the users (please follow instructions from docs xD)
Once we solved this, we were in position to configure FSLogix for the mobility of the profiles. For those who do not know FSLogix it allows to store both user profiles and applications on a centralized file share. This is extremely useful in virtual desktop environments, as the user’s profile does not have to be copied prior to boot. FSLogix will mount those profiles hosted on a file share and will make them appear local.
But again, once we have configured the entry in the VM registry:
We hit another stone… because we were logging into the WVD remote desktop and it didn’t create any profile on the Storage account, after digging and asking ourselves, we decided to go to FSLOgix logs located here: %ProgramData%\FSLogix\Logs. We checked the profile logs and found the following:
Configuration setting not found: SOFTWARE\FSLogix\Profiles\AttachVHDSDDL. Using default:
[17:33:52.257][tid:00000c4c.00000e74][INFO] Session configuration wrote (REG_SZ): SOFTWARE\FSLogix\Profiles\Sessions\S-1-5-21-1901185187-4119977032-3365905087-1004\AttachVHDSDDL = ‘D:AI(A;;GA;;;SY)(A;;GA;;;BA)(A;;GA;;;BU)(A;;GA;;;WD)(A;;GA;;;RC)(A;;GA;;;AC)S:(ML;;NW;;;LW)’
[17:33:52.273][tid:00000c4c.00000e74][INFO] Status set to 0: Success
[17:33:52.273][tid:00000c4c.00000e74][INFO] Reason set to 3: A local profile for this user exists on this system
[17:33:52.273][tid:00000c4c.00000e74][WARN: 00000003] Local profile already exists. Do nothing. (El sistema no puede encontrar la ruta especificada.)
Probably you will asking yourself what kind of error is that? It is simple, your local profile is messing with the network profile being created, so what we had to do is to remove the local profile. You can do that by going into advanced system settings and deleting the profile
We did that, and we tried again and booooooom! The profile was created in the storage account:
After doing that, we were in position to do all the test in WVD and then di all the steps to create and enterprise environment (optimization, monitoring, a “true” golden image, hide the power button, etc…).
Till nex time!
My customer had an issue where public teams are no longer showing in Teams application or Browser, whenever you go to “Join Team” or “Create Team”
Also, something weird is that the search box on the right hand of the screen was missing, so the screen that they were seeing, was similar to the following one:
So in order to solve that, you need to do the following:
Once this has been turned off, it takes about 30 minutes for the tenant to update with the changes. Take into account that some changes done via UI will take up to 24 hours (in some cases I faced it)
If you go back to ‘Join or create a team’ you should see the search box and the public teams. Probably you will need to clean cache in the browser and in the Teams App ( https://albandrodsmemory.wordpress.com/2019/01/04/microsoft-teams-how-to-clean-cache )
Hope it helps!
Imagine that you’re tweaking your Windows Firewall policies, but you realize that accidentally locked your self out from the VM, there is no console access to login and help your self back in to the system. One possible action to remediate this is to use custom script extension , where it is possible to disable the Windows Firewall to gain access again!
Step 1: Create a PowerShell script with the following code, give the script the name: DisableWindowsFirewall.ps1
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\DomainProfile' -name "EnableFirewall" -Value 0 Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\PublicProfile' -name "EnableFirewall" -Value 0 Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\Standardprofile' -name "EnableFirewall" -Value 0
Step 2: Log in to the Azure portal, and go to your virtual machine where you need the firewall to be disabled. Go the extensions, click on Add, and select a Custom Script Extension, and click create at the bottom. select the location where you save the script from step 1, and add this to the virtuall machine
Step 3: Now its time to (re)start your VM. This will allow the extension to be deployed. If you look at extensions you should see that the provisioning succeeded
Step 4: The last step is a final reboot to have the firewall really shut down. So reboot, and connect again!
I hope this helps, let me know if you have any questions
A colleague was creating a site collection from the SPO admin center and he was receiving an access denied message.
An access denied message in SPO admin center? Yes you’re reading well. First thing I propose, was to check the credentialed and the role assigned in O365 center. Everything seems correct.
Second thing, was to try to access another time to O365, but this time in private, only to check if he was having something weird in the navigator, nothing.
How I was watching the URL, by chance I tried to access to this URL, and for my surprise, this SPO URL was existing in a O365 group, so the mistery was solved!
I suggested to check the permissions of the group and to chende the managed path of O365 groups to /teams instead of /sites
Silly misconfigurations leads to big mistakes…
Today I bring a weird error, it has been hard to follow the error and reproduce it, but finally I have been able to solve it. The error was the following:
Things that I checked before finding a solution…
After digging a lot, I decided to check the traces with Fiddler, after that I was able to see a kind of redirection in the traces, so I decided to go to the Home of SharePoint tenant https://domain.sharepoint.com and check the site collection features at that level.
I was reviewing which features were activated, in order to try to clarify what was the point of that error. After checking all the features, I decided to deactivate the feature “Limited-access user permission lockdown mode”
I remember that this feature gave me some problems in the past while I was involved in OnPremises projects were we were deploying anonymous portals, so I decided to deactivate the feature.
After deactivating the feature, I checked the creation of SharePoint Team Sites with the user that was giving me problems at the beginning…. and BAM! problem solved!! Wiiiiiii
So I wonder that this SharePoint Team Site Creation Page has something related with anonymous permissions or something like that. It has been a weird problem, but finally the mistery has been resolved.
While I’m working in a project that needs to log in into a server I usually leave my user session opened (yes I know that it s not a good practice, but I always forget to log off).
So when an admin needs to connect to the server there are either no free sessions or probably the openend sessions are consuming resources that could be slowing down the server.
So as a power user, I discovered the following command to execute in PowerShell (remember to execute it as administrator) to try to list and free the unused sessions:
If you only want to see the sessions, you can execute only this:
query user | select -Skip 1 | ? {($_ -split “\s+”)[-4] -eq ‘Disc’}
To disconnect all these sessions at once, you can execute this command inside an elevated PowerShell window:
query user | select -Skip 1 | ? {($_ -split “\s+”)[-4] -eq ‘Disc’} | % {logoff ($_ -split “\s+”)[-5] /v}
And then all disconnected RDP sessions are forced logoff and the resources are free.
Till next time!
Hi all,
The other day I was creating an ADFS lab in order to test some features and configurations, as you will probably know, a quick way to test an ADFS deployment is to access the idpinitiatedsignon sign page.
After I deployed my ADFS farm, I tried to access and I received the following error message: “The resource you are trying to access is not available. Contact your administrator for more information.”
At the beginning it was annoying, because I was thinking that I did someone incorrectly, so I spend some time thinking about what I did wrong, I checked the event log and I saw the following:
Description:
Encountered error during federation passive request.
Additional Data
Protocol Name:
Relying Party:
Exception details:
Microsoft.IdentityServer.Web.IdPInitiatedSignonPageDisabledException: MSIS7012: An error occurred while processing the request. Contact your administrator for details.
at Microsoft.IdentityServer.Web.Protocols.Saml.IdpInitiatedSignOnRequestSerializer.ReadMessage(WrappedHttpListenerRequest httpRequest)
at Microsoft.IdentityServer.Web.Protocols.Saml.HttpSamlMessageFactory.CreateMessage(WrappedHttpListenerRequest httpRequest)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlContextFactory.CreateProtocolContextFromRequest(WrappedHttpListenerRequest request, ProtocolContext& protocolContext)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.CreateProtocolContext(WrappedHttpListenerRequest request)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetProtocolHandler(WrappedHttpListenerRequest request, ProtocolContext& protocolContext, PassiveProtocolHandler& protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
So, indeed what it is saying is that the idpinitiatedsignon property is disabled. So, to check if it is this, you can execute the following PS command in the ADFS farm:
Get-AdfsProperties | fl *idpinitiatedsignon*
As you can see in the picture, it was disabled, so in order to solve this problem, just run the following command:
Set-AdfsProperties -EnableIdpInitiatedSignonPage $true
After that, all my problems were solved 😊
Albandrod's Memory 