I've got a trial Azure subscription running with a couple of cloud services projects, a VM, a web app etc all up and running for a couple of weeks now.
Usage is light but resources are being consumed. i.e. stuffs been done.
My problem is the breakdown of charges re: resource groups. Perhaps I misunderstand but I thought that since every resource is put in a group and only one group by default then whatever is billed for the period should essentially be the sum of the charges for each of the resource groups?
The docs say you can get a consolidated view of resource group costs like below:
But the reality is quite different. From this summary on the portal home screen:
I can drill in to find the $48.32 expenditure:
I can drill into that and get cost by resource:
But when I want to get the cost by resource groups the info is either missing or incomplete. For these resource groups:
only one, containing a VM, has any billing data but only for compute. No data charges or storage charges.
And all the rest just have no usage or billing.
So this is kinda useless to me since we still have to dig around to find out where the difference went.
The documentation and some of the build 2015 videos suggest you can get a comprehensive view of your costs by resource group.
"how much is the marketing dept costing us"
"You can clarify billing for your organization by viewing the rolled-up costs for the entire group."
But that doesn't seem to be the case at all. Out of $48.32 of expenditure (albeit comped) only $8.43 is accounted for in resource group costings.
So have I not set something up correctly or does the portal not in fact support this?
Can I get this info by cross referencing (costs by resource IDS) with (resource group member resources id) via Powershell?
How do i get the complete operating cost (compute, storage, data) for a given resource group?
Related
We have a number of groups that come from Azure Active Directory.
Some groups contain more than 200 Users but the total is limited to 200.
Where can I set that all users are visible in the group so more than 200
This is by design a currently only a design limitation.
Azure DevOps UI will only list the first 200 members of an AAD group.
The limitation is only in what members we display, it does not impact the actual permission assignment. If you need to find the related user, you should search on the specific user directly.
I can fully understand your requirement, I suggest that you can create a suggestion ticket in the Developer Community.
I have been trawling the internet and clicking myself blue in the face! Hopefully someone has a definitive answer.
I want to have one Group (in either of Azure AD, Microsoft Teams or Azure DevOps). This group must have access to a DevOps project and a Team site. When I change the membership of the group, the membership must change for both the Team and the DevOps project. I want to avoid the overhead of managing the groups for both separately.
Is this at all possible? Thanks.
This is a really good question, and the answer is not obvious at all. Ironically we had the same exact problem in Microsoft Teams - when a user was added or deleted from the underlying Office 365 Group (which is mastered in Azure AD), it would take up to an hour, sometimes more, to be reflected in Teams, which has its own copy of the member list.
There is a way to do it, and it's how Teams does it: it relies on a relatively new feature in Microsoft Graph called subscriptions. You can find the documentation for it here: https://learn.microsoft.com/en-us/graph/api/resources/subscription?view=graph-rest-1.0.
Essentially what you want to do is create a subscription to the group: POST https://graph.microsoft.com/v1.0/subscriptions with the right message body and your endpoint will be called whenever there's a membership change in the group. Your endpoint won't know what changed, just the event and some IDs - you will likely have to make a separate call to retrieve the actual data (unless the IDs alone are sufficient).
There's a sample on GitHub that illustrates how to use Microsoft Graph subscriptions including more details on how to subscribe to group notifications specifically.
One thing to be aware of is that to use these APIs, your application will require fairly elevated permissions: Group.Read.All which means it has the ability to read not only the team/group members, but all of its messages too (among other things), for every group in your Office 365 tenant. We are working with the MS Graph team to support a less-privileged, per-group permission approach, but even after that's released for Teams Graph APIs, support for that will have to be added to the subscriptions APIs I just mentioned and that may not happen for a while.
I have a PowerBI mashup that performs 4 queries against different VSTS projects on our tenant via the VSTS Analytics module. I have setup each query as a specific analytics views. Each view returns < 200 records and are simple "Get Story Backlog items" for a single team for today only.
I am frequently getting a message like the following:
An error occurred in the ‘DS BI WorkItems’ query. Error: Request was
blocked due to exceeding usage of resource 'AnalyticsBlockingResource'
in namespace 'User'. For more information on why your request was
blocked, see the topic "Rate limits" on the Microsoft Web site
(https://go.microsoft.com/fwlink/?LinkId=823950). Details:
DataSourceKind=Visual Studio Team Services
ActivityId=a6ac93f3-549c-4eb0-b64e-2b38e18ae7ee
Url=https://vrmobility.analytics.visualstudio.com/_odata/v2.0-preview/WorkItems?$filter=((ProjectSK%20eq%208e25983d-a154-4b53-915f-1394b34e5338)%20and%20((ProjectSK%20eq%208e25983d-a154-4b53-915f-1394b34e5338%20and%20Teams/any(t:t/TeamSK%20eq%2019afa381-35ca-47db-9060-51baa5d0485e))))%20and%20Processes/any(b:(b/BacklogName%20eq%20'Stories')%20and%20((b/ProjectSK%20eq%208e25983d-a154-4b53-915f-1394b34e5338%20and%20(b/TeamSK%20eq%2019afa381-35ca-47db-9060-51baa5d0485e))))&$select=LeadTimeDays,CycleTimeDays,CompletedDate,StateCategory,ParentWorkItemId,ActivatedDate,Activity,VRAgile_ActualCompletionIteration,VRAgile_ActualUatIteration,BusinessValue,VRAgile_ChangeAreaOwnerTeam,ChangedDate,ClosedDate,CompletedWork,VRAgile_CompletionTargetConfidence,CreatedDate,FinishDate,FoundIn,WorkItemId,VRAgile_IncludedinVersion,IntegrationBuild,OriginalEstimate,VRAgile_PlannedCompletionIteration,VRAgile_PlannedUATIteration,Priority,Reason,VRAgile_ReleaseQuality,RemainingWork,vrmobility_VRAgile_RequestedBy,VRAgile_RequestedDept,R...
error=Record
I have checked the page and looked at the Usage page on our VSTS tenant but during these times my user is not indicated as blocked and VSTS user interface works normally.
The issue goes away after a few minutes but it will then return after a couple of changes made in PowerBI (like adding a new column, changing data type etc) because this automatically refreshes all 4 queries again and this seems to trigger this unacceptable usage.
It is really frustrating as I can't continue working on the report and have to go and do something else for 5 minutes really impacting my flow.
Any ideas on cause, solution/workarounds? It feels to me like an overly sensitive VSTS limit on the VSTS Analytic service
Azure DevOps Services limits the resources individuals can consume and the number of requests they can make to certain commands. When these limits are exceeded, subsequent requests may be either delayed or blocked.
See the below link...
https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops
I want to monitor employees interactions inside companies. In the case the company is using Gmail, I was thinking about using https://developers.google.com/admin-sdk/email-audit/.
But i still have some questions regarding the "lawful" purpose and I'm wondering if Email Audit is the right API if my purpose is to monitor in real-time emails knowing there will be at least 10 000 emails/day to monitor.
If you check the Usage Limits and Quotas:
Limits and quotas protect the Google infrastructure from an automated process that uses the Email Audit API in an inappropriate way. Excessive requests from an API might result from a harmless typo, or may result from an inefficiently designed system that makes needless API calls. Regardless of the cause, blocking traffic from a specific source once it reaches a certain level is necessary for the overall health of the Google Apps system. It ensures that one developer's actions cannot negatively impact the larger community.
To answer you question, if your goals falls under this description - Google Apps Email Audit API Developer's Guide:
The Google Apps Email Audit API allows Google Apps administrators to audit a user's email, email drafts, and archived chats. In addition, a domain administrator can retrieve account login information and download a user's mailbox. This API can be used only for lawful purposes in accordance with your Customer Agreement.
Then the answer would be yes, it is the appropriate API to use. If you are thinking about the 10000 emails/day, you might want to check if it is reasonable to ask for quota increase.
Hope this helps!
How do you get the total number of users in a Google Apps Domain? I'm aware of the "Retrieve All Users in Domain" call using the Google Provisioning API, but I'd rather not execute such an intensive call just to count up all the users. Is there a simpler way to do this?
I found a solution that isn't as resource-heavy as retrieving all users: The Google Reporting API can be used to get the total number of accounts in a Google Apps domain.
The Google Apps Admin Settings API allows you to retrieve both the current and maximum number of users in the domain:
https://developers.google.com/google-apps/admin-settings/#retrieving_the_current_number_of_users_in_a_domain
this would be preferable to the reports API as it's both lower in traffic and it's closer to real time (reports are only updated every 24 hours so it won't take into account users recently added).
You could try "Retrieve All Nicknames in Domain" which could save some bandwidth as it hopefully really only retrieves the nicknames, although I think this won't get you the exact count because "Retrieve All Nicknames for a User" seems to imply that a user can have multiple nicknames.
If you've got some test domain, also assure that retrieving all users really is too much overhead and keep in mind that depending on what you want to do, you can perhaps build some kind of cache around it that only does a full request after the cache is older than X.