A client has tasked my team with building a responsive web application (angular based) for them using Visual Studio and Visual Studio Team Services. The client is hosting the Team Services instance that our team is using. Our developers will be able to get Basic access for Team Services on the client's instance via their developer Visual Studio Pro MSDN subscription IDs. But, we have a bunch of non-developer functional members of my team (scrum master, analysts and testers) that need Team Services access on the client's Team Services instance and getting that has been difficult to do.
The testers will need Advanced access for Team Services and all others will need Basic access. The client does not want to be billed specifically for any of my team's Team Services users who they can't add/link with existing MSDN subscriptions. Because I am not typically doing work on the MSFT stack/tools, I do not want to procure MSDN subscriptions from a cost stand point for all of our non-functional folks, which includes my testers. It would seem to me that based on the SAS model afforded by Team Services and based on the fact that our non-developers don't use Visual Studio that purchasing MSDN licenses just to be able to use Team Services accounts would not make sense for me.
Is there a way for us to either:
Add the non-developer Team Services accounts on my Team Services instance on our Azure account and then get them added to the client Team Services, so that all incurred billing will be made to my account?
Is there anyway we can add Team Services accounts on the client's Team Services instance and specify a different bill to account for specific accounts?
Thanks in advance!
Based on the requirements, most or all of your scrum masters and analysts may qualify as stake holders. A Visual Studio Team Services account can have unlimited stake holders (they can add and edit work items and bugs, plus can view your dashboards, backlog, and Kanban boards) for free.
For the testers, depending on what they need, you can additional Basic licenses for $20 a month. You can get more details on the Visual Studio Team Services pricing page.
With regards to the actual billing question, I am not sure if/how to do either of the options you are looking for.
As all of your Testers require to access the software you are building, and those machines are likely licenced by your MSDN then they do indeed need an MSDN licence. Access to environments for testers, access to Microsoft Test Manager, and advanced test management tools all need an MSDN and you can get the Test Professional SKU for them.
If your analysts need access to the environments then they also need MSDN.
If the customer wants you to work in their VSO then either you get MSDN or they buy the required licences. If you are a vendor then I would expect you to have the appropriate licences for developing the software that you are commissioned for.
Related
I want to publish a maintenance update to a VSCode extension that I once published.
I published the extension while I was at university X, and now I am at university Y. Stupidly, I had used my university X email address for creating the Azure DevOps account for publishing the extension, and this email address does no longer exist, so I lost access to the Azure DevOps account. I still have access to the Github account of the source repository of the extension, so I can "prove" that I am the author.
I believe that as the author of an extension with a few hundred users it is well in the interest of Microsoft to support me with this. The problem is that since I am not a business customer of Microsoft, I see no way to contact them at all. Does someone have a support email address, perhaps?
If preferred, you can also contact me directly via https://chat.stackoverflow.com/users/10190810/david.
Before following any technical advice, you should first identify if there is any copyright/patent issue you neglected. "I published the extension while I was at university X" might be an indicator of such issues if you were employed in anyway and the actual work contracts might force you to grant copyright to the university. Be warned that some contracts don't even allow you to publish such on your own, so there might be bigger problems (the typical your code is not yours situation).
Once you iron out the non-technical part, it might be a good thing to end that old extension publisher account completely and start all over with a new publisher account.
Could someone throw some light on the difference between basic and Visual Studio professional subscription access levels in Azure DevOps?
Microsoft document here provides abstract information regarding the different access levels.
We have few users who are tagged with basic access level (who also have Visual Studio Professional Subscription) while few other users with Visual Studio professional subscription.
It is understood from this link that basic access level subscription billed $6 per month, the question that arises now is if azure devops is available for usage without cost if the user has visual studio professional subscription, and do we need to buy basic access level for users who do not have Visual studio professional subscription.
The difference between basic and Visual Studio professional
subscription access levels in Azure DevOps?
First, assume this professional subscription is available, not expired.
For active and valid subscription, it has all features of Basic. And also, as a VS Subscriber, you will have a basic license which included in VS subscription. Meanwhile, you can also use a range of features in Azure DevOps that are included with your subscription as a benefit.
For example, the subscribers have Basic + Test Plans included with their subscription. But for basic user, their Test Plan need be purchased additionally.
But, if the user don't have valid subscription or expired, at this time, this user will work as Stackholder.
Do we need to buy basic access level for users who do not have Visual
studio professional subscription.
As I mentioned previously, the Basic feature is included in the Visual Studio Professional Subscription. So, about these users, you don't need worry about their permission, just pay attention for not expired.
But, for the users who do not have the Visual Studio Professional Subscription, you only have 5 free Basic feature. If these free quotas are used up. You must buy the Basic for them.
Update:
You can see that in the Users tab, and also can get clearly know that who has subscriber level, who just has Basic level and who own Basic + Test Plan:
Can a user that has a Visual Studio subscription be given only "stakeholder" access? That way they can still use Visual Studio for their purposes, but as for VSTS and a team project, they can only do things such as enter bugs, get to the kanban boards (and update it if needed), define sprints etc. Basically "management stuff".
VSTS automatically assigns them Basic features, if your account has
seats available, or Stakeholder features, if not. -Microsoft Docs
What this effectively means is that VSTS will upgrade your user to the highest available license when the user logs in.
Any unassigned Basic License registered to your account automatically get assigned to stakeholders as they log in. (based on Microsoft Docs)
The same auto upgrade happens when the user have some sort of MSDN license. (based on personal experience)
So due to the auto upgrade process, trying to keep a user in the Stakeholder License as a means to restrict access might be a losing battle. You might want to modify permissions around this user instead or create a custom security group between Readers and Contributors.
I developed an Office Word add-in that I'd like to make available to organizations as well as single users. I understand that the AppSource will only grant licenses to single users, and that if I want to distribute to organizations I must create my own licensing and accounting backend[1] and have an IT professional at the purchasing organization run a centralized deployment of the add-in.
My question deals with finding the best practice to offer the app on AppSource such that both an single user and an enterprise client can deploy the app straight from AppSource.
The rub is that I'm not willing to make my app free, which is a requirement for Centralized Deployment[3]:
You may only add free add-ins from AppSource; adding paid add-ins isn't currently supported.
So, I'm thinking that I can't multipurpose my add-in on the AppSource and instead either:
Provide two add-in products in app source. One that does token checks only, and another that does user identity checks only. The second one being "free" on AppSource and Centralized Deployment friendly.
Only provide a token-based app in AppSource, and create a secondary manifest that I provide to organizational purchasers.
Both solutions are clunky and my aim to simplify the code base. I'm basically wondering what is the standard(best) practice(s) to provide an AppSource add-in that can serve both individual and organizational users?
Personally I'd make the add-in free and use your own licensing backend to allow users to activate the functionality. This is common practice for other addins
Thanks
Phil
Is there any way to automatically purchase new licenses for VSTS users? There's API's for adding users and adding entitlements, but I can't find anything for buying new licenses.
There isn’t he API to buy the new license, you can change another’s’ access level to Stakeholder and change the new added user’s access level to Basic if someone do not need the basic access level.
User Entitlements - Update User Entitlement
On the other hand, you just need to add user to VSTS who has the Visual Studio Enterprise subscription.
I scanned through the full list of APIs supported by Visual Studio Team Services (VSTS) and Team Foundation Services (TFS) documented Here. AFAIk, there is no API exposed to automatically purchase new express/basic licenses for VSTS users.
I concur with raterus. Can you please elaborate on your use case and we can attempt to prescribe an alternate solution.
The use case: Azure DevOps (ADO) bills you directly for reserved license space. I.e. I can buy space for 2000 basic licenses within an ADO-organization and even if no one is active (utilizing a basic license) my company gets billed for the 2000 inactive users per month. So as a ADO admin you buy a little license space extra for new users that join, when you run out of it you buy a little extra space again.
I am currently in the process where we slowly ramp up to approximately 4000+ ADO users over a couple of years. People are allowed to join the ADO-org through AD group membership, the moment they become active they take a basic license (if there is licensespace) otherwise they get assigned a stakeholder license. Which you have to correct by hand, mostly after user is baffled as they can't clone the git repo after having carefully followed the readme.
All in all a cumbersome manual environment, please allow me to automate the user management. Or change the license model to not bill unusued license space, then I can set the cap to 4000 and I am fine.
What is possible
detecting low license space, with a cronned pipeline we can send an alert to remediate
adding removing users and licenses, typically run at the last day of the month to remove inactive users (for them invisible as they get the license back once they return through their AD group membership)