Saturday, February 10, 2024
Thursday, May 12, 2022
Guest Users and Project for the web
We now have guest access in Project for the web, but in the early testing we have seen some anomalies raised by customers (and MVPs - thanks Erik and Paul). There are a lot of settings across M365 that control what guests can do - but none appeared to explain the difference we were seeing from tenant to tenant. So, what was different and what can you do about it? First, I'll explain the difference I was seeing.
In one tenant (see screenshot above) I could add an existing guest (you can't invite new guests from Project - that is expected) and it allowed me to choose between adding them to the group or just making an assignment. I could also add them manually to the members list. All good! In my other test tenant, I could add them to a task, and they were assigned - but not added to the group - and listed instead as "other people" - and I couldn't see them listed to add them to a group - at least in Project (I could in Outlook or AAD).
On the face of it everything looked the same about the guest user (it was the same account) and even the tenant. A quick play around with F12 developer tools and I could see when I browsed to add a new member and it was not finding the guest, the actual query had a filter - "userType%20ne%20%27Guest%27" - so not suprising that my guest wasn't found! I then tried Ctrl-F5 to fully refresh the page and look through the other calls going to the service, to see if there was any clue to why it wasn't looking for guests. These few calls looked like they were getting various settings that might impact the page:
and without too much looking I found that "GroupSettings" looked interesting. It was calling out to an API to get TenantSetting/GroupSettings. The response it got was {"value":[]} - basically a NULL array. Odd. I tried the same thing on my working tenant and saw the response as this:
{"value":[{"displayName":"Group.Unified","templateId":"62375ab9-6b52-47ed-826b-58e47e0e304b","id":"3c4adb15-25c8-48a5-b060-106e025803a2","values":[{"name":"NewUnifiedGroupWritebackDefault","value":"True"},{"name":"EnableMIPLabels","value":"True"},{"name":"CustomBlockedWordsList","value":""},{"name":"EnableMSStandardBlockedWords","value":"False"},{"name":"ClassificationDescriptions","value":""},{"name":"DefaultClassification","value":""},{"name":"PrefixSuffixNamingRequirement","value":""},{"name":"AllowGuestsToBeGroupOwner","value":"False"},{"name":"AllowGuestsToAccessGroups","value":"True"},{"name":"GuestUsageGuidelinesUrl","value":""},{"name":"GroupCreationAllowedGroupId","value":""},{"name":"AllowToAddGuests","value":"True"},{"name":"UsageGuidelinesUrl","value":"https://guideline.example.com"},{"name":"ClassificationList","value":""},{"name":"EnableGroupCreation","value":"True"}]}]}
This looked familiar as I'd set some of these values in the past using PowerShell. A great article that describes all this can be found at Azure Active Directory cmdlets for configuring group settings . I looked at both of my tenants to see what settings were present, using Get-AzureADDirectorySetting -All $true. My tenant that didn't resolve the guest came back empty:
In my tenant that did show some settings I saw what I expected:
It appeared that I had no specific settings configured, and in that case the NULL array returned didn't give Project the information it needed to know that guests were ok to resolve. I'm not sure at this point whose bug this is - Azure AD for not having any defaults show up - or Project for not filling in the gaps. We will see who gets to fix it. But to fix it yourself you just need your tenant admin to follow steps in the article listed above to set the settings they want - and assuming they don't block guests you should then be able to assign and add guests to your projects and they will be members. CTRL-F5 once the Group Settings are present, and then I can add my guest to members:
Posted at https://sl.advdat.com/37Lfp4khttps://sl.advdat.com/37Lfp4k
Experiencing Data Access Issue for Log Analytics in North Central US - 05/12 - Resolved
Final Update: Thursday, 12 May 2022 20:53 UTC
We've confirmed that all systems are back to normal with no customer impact as of 05/12, 19:48 UTC. Our logs show the incident started on 05/12, 19:11 UTC and that during the 37 minutes that it took to resolve the issue some of the customers using Log Analytics in North Central US Region may have experienced issues accessing data as well as missed or delayed Alerts.
-Jayadev
We've confirmed that all systems are back to normal with no customer impact as of 05/12, 19:48 UTC. Our logs show the incident started on 05/12, 19:11 UTC and that during the 37 minutes that it took to resolve the issue some of the customers using Log Analytics in North Central US Region may have experienced issues accessing data as well as missed or delayed Alerts.
- Root Cause: The failure was due to issues with one of the backend Services.
- Incident Timeline: 37 minutes - 05/12, 19:11 UTC through 05/12, 19:48 UTC
-Jayadev
New Release: SharePointDsc v5.2 has been published!
This new release of SharePointDsc includes one new resource (SPSearchCrawlDatabase), improved logging and several bugfixes. It also includes a fix for a bug introduced in v5.1, where the SPSearchIndexPartition would only return the first server running the index partition. Checkout the change log below for more information about all changes.
You can find the SharePointDsc v5.2 in the PowerShell Gallery.
NOTE: We can always use additional help in making SharePointDsc even better. So, if you are interested in contributing to SharePointDsc, check-out the open issues in the issue list, check-out this post in our Wiki or leave a comment on this blog post.
Improvement/Fixes in v5.2:
Added
- SharePointDsc
- Added the SPShellAdmin resource to the ReverseDsc export
- Updated ReverseDsc version requirement to 2.0.0.11
- SPFarmPropertyBag
- Added support for boolean and int32 data types
- SPInstall
- Added additional ExitCode for incorrect license key
- SPSearchCrawlDatabase
- New resource
- SPSearchIndexPartition
- Added additional logging to improve troubleshooting
- SPShellAdmin
- Added additional logging to improve troubleshooting
- Added Export logic
- SPWebAppPeoplePickerSettings
- Added the CustomFilter parameter to the resource
- Added the ShortDomainName parameter to the resource
Fixed
- SharePointDsc
- Fixed incorrect table formatting in the resource table of the Wiki
- SPSearchIndexPartition
- Fixed issue where only one index component was returned after a regression issue in v5.1
- SPSearchServiceApp
- Fixed issue where the database permissions were not corrected for new search service applications.
- SPShellAdmin
- Fixed issue where the farm account was the owner of the database. Now including the farm account in those cases.
- SPWebApplication
- Fixed an issue where the Set method tried to use the Parameter SecureSocketsLayer with Set-SPWebApplication on SharePoint Server older than Subscription Edition.
- SPWebAppPeoplePickerSettings
- Fixed an issue where the Set method would not update a non-mandatory parameter on an existing SPWebAppPPSearchDomain
A huge thanks to the following guys helping with submitting Pull Requests, testing deployments and submitting issues:
Christoph Hannappel and Bart Vermeersch!
Also, a huge thanks to everybody else who submitted issues and all that support this project. It wasn’t possible without all of your help!
For more information about how to install and use SharePointDsc, check our Wiki.
Let us know in the comments what you think of this release! If you find any issues, please submit them in the issue list on GitHub.
Happy SharePointing!!
Posted at https://sl.advdat.com/37Fy5lZhttps://sl.advdat.com/37Fy5lZ
Zyxel silently fixes critical RCE vulnerability in firewall products
Threat analysts who discovered a vulnerability affecting multiple Zyxel products report that the network equipment company fixed it via a silent update pushed out two weeks ago. [...]
Posted at https://sl.advdat.com/3wkVH7L
Subscribe to:
Posts (Atom)