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
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…).
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!!
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
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
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.
After a looong time without installing a new SharePoint farm, yesterday it was the day 🙂 I needed to install a new farm, so I started doing it and it was everything so simple. After I installed the farm I was reveiwing the Event Viewer in order to see any errors, and I realize that the farm was throwing a lot of errors complaining about “UserProfileApplicationProxy Proxy is null”
The error itself, makes sense since I did not provisioned the User Profile Service Application, so what can I do? Disable the timers of course 🙂
Log in to Central Administration
Click the Monitoring link on the left and then under Timer Jobs click Review job definitions
On the left click Job History
Change the View from All to Failed Jobs
Click the link for the failed job – in my case I am disabling the following jobs:- UserProfileApplicationProxy – Per Database User Profile to SharePoint Full Synchronization
– UserProfileApplicationProxy – Unified Group Processing High Performance Job
And that’s all, problem solved and not more errors in the event viewer. To the next thing!