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!
Have you ever faced this problem in a Intel i7 5th generation?
As you can see in the image the processor is not supported, but how we can solve that problem? With a registry entry!
You can go to the regedit and add the following reg entry:
The same reg registry can work for unsupported TPM…
Good luck and till next time!
I have been testing auto apply label in some scenarios, but what I have discovered is that AutoApply Label is not working when I activate the autosave toogle in Word (for example):
I’ve been testing the same policy under different circumstances (Windows 10 + Office 2101 C2R)
Turned ON AutoSave for synced libraries (Default On):
Tested to create a new Word.docx where AutoSave in ON and then added keyword in doc to trigger AutoApply label.
After hit Safe nothing happens, no label applied (or suggested)
Turned OFF AutoSave for synced libraries (Default On):
Tested to create a new Word.docx where AutoSave in OFF and then added keyword in doc to trigger AutoApply label.
After hit Safe the Auto Apply label suggests me to change label.
I will keep tracking that problem…
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!
If you’re implementing conditional access in your company and you’re struggling with Windows 10 devices and Chrome support, probably you will need to visit that Docs link: https://docs.microsoft.com/es-es/azure/active-directory/conditional-access/concept-conditional-access-conditions#chrome-support
But in this post, I want to talk about something related to it, in one of my projects, I have a CA policy that required one of the following selected controls: Require MFA or Require Hybrid AAD joined device
My device was Hybrid, so I was fullfilling one of the requirements, for example, when I was accessing with IE or Edge, the device info gets passed properly and MFA is bypassed for hybrid AAD machines.
But with Chrome, even having the Windows 10 Account extension pushed via GPO, I was able to see in the azure sign-in logs that device info is blank except for Browser and OS, so the AAD join status is not passed and MFA triggers. So it was very weird and it was causing me some problems…
So finally, after hours of troubleshooting, i finally figured out what was wrong. When you automatically install the extension, it doesn’t clear some cookies which Chrome will then try to use the old way of logging in. So in this case what you will need to do is access to chrome://settings/content/all and delete the cookies for login.microsoftonline.com
After doing that, everything was working perfectly, keep aware of that!!
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
While I was doing a implementation in a customer, I faced a weird thing, I created a new Site Collection, and when I was trying to invite people that I had in the B2B tenant, I was not able to find them.
If I tried with an internal users, I was able to find them, so I was sure that the problem was with the external users.
The first thing that I checked, was the properties of the SC to be sure that I can invite external users, and of course I checked this parameter at tenant level, was with no luck.
So, I started to check commands in Docs, and I found a command very interesting: ShowpeoplepickerSuggestionForGuestUsers
So I decided to give it a shot:
Once executed the last command, I was able to find guest users
Mistery solved!!
Currently, I faced a weird problem, I was trying to implement an App solution into a customer catalog, but every time I tried to deploy the solution, it was impossible to be deployed.
The weird thing here, that I have a development tenant, were I am able to deploy the app without problem, so I was struggling into it to discover what was the real problem.
So after deploying several time the app into the catalog, I accessed to the “Integrated Apps” inside Services, and I realized that this was turned off. So… after turning on this feature I was able to deploy correctly the app and the problem was solved.
For more info for how to turn on the the apps: https://docs.microsoft.com/en-us/office365/admin/misc/integrated-apps?view=o365-worldwide
Albandrod's Memory 