enter image description hereTwo of Azure Enterprise applications were showing below options till yesterday night under Manage blade:
Properties, Owners, Users and Groups, Provisioning, Application Proxy and Self-Service.
But, today I am seeing only three options, rest are missing: Properties, Owners and Provisioning
In the absence of Users and Groups, the owner of the applications can't add users or groups to this application.
In spite of having global admin access I can't see those missing options, The owner of these two Enterprise Applications also can't see those missing options.
None, of the MS article, talks about this issue, can someone please help how to get those options back.
It looks fine on my side. If you did nothing and the buttons disappeared, you need to raise a support ticket on Azure portal by following this link.
Related
I have created a dashboard with a few widgets which runs varies queries to change the visualisations.I would like to share the dashboard alone but unable to do so via publishing it as the dropdowns are removed in the published dashboard.
is there any solution to this problem without integrating any other third party visualisation tools.
searched various documentation for the solution but could not find any hints.
Widgets should be visible when you share the dashboard. Double check the permissions the dashboard receiver has as well as the sharing setting (which credentials are used when running the queries behind the dashboard).
For more details, refer to Dashboard access control
Note: If permissions look okay you could file a support ticket via the portal for further investigation.
FYI - There are more publishing options for dashboards in the roadmap.
I have been building canvas apps as part of solutions on non-default environments for a while.
Recently a customer required that the app be shared (to run, not edit) with an AAD security group's members.
The SG setup is as follows;
Image of SG setup
I imagined this to be simple and indeed I was able to 'Share' the canvas app with the SG.
However, users were unable to access the app even via a direct URL unless I gave them individual access.
I have spent many hours perusing the documentation and it seems that it is all aimed at 'Dynamics/CDS' environments.
The only way that i was able to share the app to them using the SG, was to create an environment DB add then to set the SG as the env SG.
Is that the correct approach?
It seems counter-intuitive because, according to MS, if an SG is not set to an environment, then all users can access the env?
First, make sure the group you are sharing with is really a security group or security-enabled M365 group.
You can't share an app with a distribution group in your organization or with a group outside your organization.
...
You can share an app with Microsoft 365 groups. However, the group must have security enabled
You can do that at Azure Portal:
Go to Azure AD Active Directory > Groups (direct URL)
Click [Columns] and add Security enabled column to the list
Find the group and make sure it is security-enabled
Also, make sure users have permissions to access and other resources
For a shared app to function as you expect, you must also manage permissions for the data source or sources on which the app is based, such as Microsoft Dataverse or Excel. You might also need to share other resources on which the app depends, such as flows, gateways, or connections.
Source: https://learn.microsoft.com/en-us/powerapps/maker/canvas-apps/share-app
I have this team project in Azure DevOps (previously known as VSTS):
$\TempProjectA
I have this developer that can log into Azure DevOps and develop code:
username: first_developer#example-company.com
password: *****
I have this group that is called SingleFileReaders, and I've added first_developer#example-company.com to this group.
Then using Visual Studio's Source Control Explorer, I've browsed to $\TeamProjectA\FileToBeShared.java, right clicked on it, using Advanced menu I managed to get to Security pop-up. And there, I allowed the read option.
Now I login as first_developer#example-company.com into Visual Studio, but I don't see that file. In fact, I don't see TeamProjectA. What should I do?
You Should add the developer to the Project Team members, with contributor role.
Follow here, Since the UI is changed there are some difficulties to find the securities/adding user configuration in Azure DevOps
Security
Contributor role to access the Source codes
For anyone who's stuck in this point, the trick is to give View project-level information permission to your role/user first. Using built-in roles is not helpful as they have permissions much more than what I wanted. They give access to all files, at least read-only permission.
We have added Application Insights to our app, but I'm unable to make the application insights data availible to other developers (azure users). This is what I've tried:
Added a new Resource Group
Added a new Application Resource to it
Added a colleague that has another azure subscription, added as role Contributor to the resource group
Verified that the user is listed as inherited access in the application insight resource
Application insights data is showing up fine in my portal, problem is that my colluages are not able to locate the resource or the resource group in her azure portal. I've tried by sending a link, but the azure portal just says "loading"
Question is: Do I need to give some other access to allow for sharing application insights?
Thanks for any help
Larsi
Since you mention "developer" I'm assuming you are both using separate MSDN subscriptions, and thats whats causing the issue. If this is the scenario that you are each using your own MSDN subscriptions when you log in, the other developer need to "switch" to your "directory" after they sign in, in order to see the things you gave them access to. Once the other dev is logged in to the azure portal, have them click their name in the upper right of the browser window, and in that dropdown there will likely be an additional "directory" that they can select which effectively switches them to see things that are inside your subscription+directory. Its this extra level of the "Directory" that is probably hiding your AI resource from him.
I experienced this problem first hand in the exact scenario you have described.
There is a lot of information about setting up access control for Application Insights here: https://azure.microsoft.com/en-us/documentation/articles/app-insights-resources-roles-access-control/
It looks like you've done most of those things, but you might want to double check just in case. Also, you shouldn't need to assign them "contributor", which would allow them to edit things, you should only need to give them "reader" access so they can see the data.
We're completely upgrading our production and development environment from co-located boxes to an Azure implementation and we'll be developing using Visual Studio Online. Up until this point our dev has occurred on a Remote Desktop environment where developers were logging into Windows server and developing on that RDP box.
We want to set this up and we have some confusion about the Account types/set up types.
It appears there are two ways to set up our Azure and two ways to set up our developers. We are a MS partner w/ some MSDN licenses and Azure credits.
So for Azure we can use our existing MS accounts and just set up an Azure Pay As You Go (PAYG) subscription. This was suggested to us initially but it seems weird to have the entire companies Azure environment going through an individuals live ID. Then we saw we can sign up as an Organization now and it uses Azure AD. We have not been using Active Directory and we're not sure how much complexity this is going to add to our administration. Is there a discernible difference/benefit to going one way or the other?
Then, when we sign up our developers we can either have everyone sign up with their live ID's (we have MSDN w/ VS Premium credits for all developers) or we can set them up using Active Directory with Work Accounts. Having our credits allotted in work accounts sounds like a good way to control things at first reading, but it also seems a bit more complex. I'm wondering if there is much difference between MSDN accounts signed up w/ live IDs or AD Work Accounts. I can't find a real comparison article or pro/con type of discussion anywhere.
It sounds like you have already figured out the main differences. As an organization, I would suggest signing up for Azure as an organization. You can do that here. This is going to give you the management capabilities for resources typically needed by an organization.
Your developers can continue to use the MSDN subscriptions. As Dylan commented, these are not to be used for production environments. You should consider using these for Dev/Test environments and activating your MSDN benefits. This will save you some money. More on that here.
Visual Studio Online will work with your Work Accounts and again give you more control over managing your online resources. This link describes the sign-up process for both Microsoft Accounts and Work Accounts. And if you scroll down a bit you will find your original question specifically addressed.
Finally, you can also add your Work Account(s) to your existing MSDN subscriptions if you like. This way you (and your developers) can use the same account credentials when accessing Azure Subscriptions. Information on how to do that is available in this link.
Your Work Account subscription should be limited to personnel responsible for managing your "production" environment.
After signing up for Azure as an Organization, you can add users to the directory as described here. You can also add "external" users using their existing Microsoft Accounts. It's just a few dialogs to add a user.