Identity
12 TopicsAccess Denied: Development Pathways Restricted by Protocol BARRIERS_MX-502
Microsoft Build 2024 was anticipated with excitement, but the reality was more disheartening. Valuable tools and learning resources, discussed extensively at Build, remain inaccessible to many developers due to restrictive access requirements. Accessing Microsoft's development pathways has become increasingly difficult for independent developers, particularly with the introduction of Copilot Studio. Despite the excitement around its potential, the requirement for an organizational 'work' or 'school' account creates a significant barrier. Microsoft 365 business subscriptions, necessary for these organizational accounts, are not feasible for many individual developers due to their cost and the nature of their work. Additionally, the alternative—an MSDN subscription—is not a practical solution for everyone. This situation leaves many developers unable to experiment with and utilize Copilot Studio and other advanced tools. The frustration is palpable, as independent developers are effectively excluded from accessing resources that could enhance their skills and contributions. At this year's Build conference, the excitement around new tools and features quickly turned to disappointment for many. The realization that these tools were out of reach due to restrictive access requirements overshadowed the innovations presented. This practice seems inconsistent with Microsoft's open-source philosophy and its stated commitment to fostering a diverse and inclusive developer community. It’s a frustrating reality for many developers who are eager to learn and innovate but are hindered by access barriers. Moreover, this exclusionary practice contradicts the principles of Responsible AI Practices. By restricting access to advanced development tools like Copilot Studio, Microsoft is inadvertently creating a divide that hampers the inclusive growth and ethical deployment of AI technologies. Ensuring broad and equitable access is crucial for the responsible advancement of AI, and current policies need to reflect this imperative. Barriers hinder innovation. Deleted326Views0likes0CommentsHow to protect data and secure devices with Intune [App Protection Policy] 📱🔒
Protecting organization's data on mobile devices is crucial for companies. In this video, I'll talk about Microsoft Intune and how you can leverage the capabilities of App Protection Policy to secure your company data on mobile devices. Some scenarios covered include allowing copy/paste between trusted apps, avoiding screenshots and screen recording of organization data, sharing files only between managed apps, adding a PIN to access, and encrypting data. #DataProtection #MobileSecurity #MicrosoftIntune :mobile_phone::locked:348Views0likes0CommentsRecommendation - Microsoft 365 authorisation concepts - Part 1
[New Blog Post] *PART 1!* I have put a new article online. This article is divided into two parts. In these two parts, you will learn the most important things about #AdministrativeUnits in #EntraID. What needs to be considered when creating an authorization concept. https://www.msb365.blog/?p=5495 #MVPsummit #M365 #Microsoft365 #CommunityRocks249Views0likes0CommentsAdding an alias for office365 user(s) Synchronized using ADSync
I am trying to add an alias for users synchronized with AD using ADSync. Adding SMTP and smtp in ProxyAddress attribute is not working; receiving Sync errors (removed automatically). Any assistance would be helpful.490Views0likes2CommentsAdding Subdomain to Entra ID but gets set automatically as federated.
I have a customer that is trying to added a subdomain (subdomain.contoso.com) to entra id for cloud only user accounts. Curranty they have the root domain (contoso.com) syncing from onprem AD that is federated but this subdomain should not be tied back to that domain. I have tried these scripts with only errors. Set-MsolDomainAuthentication -DomainName subdomain.domain.edu -Authentication managed. *********** Connect-AzureAD New-AzureADDomain -Name subdomain.domain.edu Connect-MgGraph -Scopes Domain.ReadWrite.All Update-MgDomain -DomainId subdomain.domain.edu -BodyParameter @{isRoot=$true} ERROR - Update-MgDomain : isRoot property is read-only. *********** Any assistance with this would be appreciated.1.3KViews0likes4CommentsBest Model for Multi-Tenants
I am trying to determine the best model for ourscenario, which is not unique. We currently have four separate tenants. One is the parent (holding company) and the other three are separate subsidiaries. We currently have all tenants set up with cross-tenant access and synchronization between each, in what I would refer to as a mesh model. As we add more subsidiaries, this becomes more complicated. I now wonder if it would be better to create the connections and synchronization from the subsidiaries to the parent company only. Then the part company tenant handles the selection of users and resources to synchronize with the various subsidiaries. Just looking for any input on this as I don’t want to continue down the incorrect path.509Views0likes2CommentsGet Delve skills with MgGraph PowerShell
Today I was asked to get a report for the Users skills published in Delve. It took a while to figure out how to do it, but finally it's really easy with MgGraph. See the commands below: - First we need to install the Beta People Module Install-Module Microsoft.Graph.Beta.People - Then import the module Import-Module Microsoft.Graph.Beta.People - The connection should use the scope User.Read.All Connect-MgGraph -Scopes User.Read.All - Then you can use the following command to get the required information Get-MgBetaUserProfileSkill -UserId <user email address> The output isn´t as clean as desired: So, after a pipe FL I found what I really need, the Skill Display Name: Get-MgBetaUserProfileSkill -UserId <user email address> | fl displayname An this is the output: Here you can find more information about this Beta commands and also much more possibilities of getting users information. Very useful: List skills - Microsoft Graph beta | Microsoft Learn867Views0likes0Commentsadding acquired company to existing O365 Tenant
Our Company A (Hybrid AD) acquired Company B (Entra ID Only and Azure environment) with less than 50 users. We want the company B users to continue to use their domain with Company A 0365 environment but not migrate them to our AD. Company A uses Okta as IdP/SAML and we would also want Company B users to Okta for SAML as well. This is the first time I'm having to do this. Where do I start? What's the first step should I take to do this. Do I create a trust in Azure? Thank you885Views0likes2Comments