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
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:
The service is not started.
Your account is not a member of a required security group.
See the Synchronization Service documentation for details
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…
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…
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…).
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
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
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:
The user tries to create a SharePoint Team Site from the portal
The user selects a Team Site and starts to fill the parameters
The problem here, is that it stucks on the “Checking” action to verify if the site exists wether or not, and after a few moments it shows a message to exit from the creation site page. In case the user selects “Stays on this webpage” the system does nothing, but in case the user selects “Exit from this page” it automatically fires the following error:
500 Internal Server Error, a great error take into account that we are talking about SharePoint Online…
Things that I checked before finding a solution…
Check if the problem was reproduced with other navigators… I tested with IE, Edge, Chrome, Firefox and SAfari, all of them had the same behaviour.
Check if the client has configured a group to restrict the creation of O365 groups
Check if it happens with all the users, yes it happens
Check if it happens with global administrators, nop the GA were able to create the groups
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.
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:
Encountered error during federation passive request.
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: