In our company we automated certain things for our customers:
Reporting, (counting Azure AD accounts, systems, mailboxes);
Create user (setting all permissions);
Create mailboxes;
managing tickets in ITSM;
Delete user .
We did use a lot of Powershell scripts and Azure Devops to automate these tasks. Now with the deprecation of basic authentication, we had to change our scripts and the way of authentication to all of our customers' Exchange Online. This made us think, is there a better way to set this up not to have these problems? We are already working with configfiles, modules, classes in our scripts.
What would be the best way to automate these tasks and not have the rework when Microsoft changes the authentication method?
Another question what would be a way to automate these tasks in low code?
The situation is that we make connection with the Azure Platform from our customers.
If you already work with modules and classes you should probably write a single "authentication" module/class that is then used in all of the subsequent scripts. If and when MS change the authentication method again - one only needs to change this one class that is called by every other script.
In terms of "low code" - it depends on what these tasks are doing.. but, one is able to use the Power Platform Office365 Connector and from there it is possible to query AAD. There is also the GraphAPI.
It really depends on your use case but the following link may be of some assistance with the "low code" question:
https://powerusers.microsoft.com/t5/Building-Power-Apps/Query-Active-Directory/td-p/724376
Related
Working with a on premise customer in a closed on premise environment.
Need to set up some scheduled import/export jobs which involves the exchange of data between their systems. Most follow this process: extract data from one system, call an endpoint of another system to add/update data.
Normally I would make these as webservices and use Azure Scheduler/batch to call them or a middleware solution such as Kafka however these options are not available for this customer.
What is the best practice these days to do scheduling without the tools above? Windows scheduler?
Also are there any tools/programming techniques to deal with failure/retry scenarios
Thanks in advance!
A working Azure Data Factory (ADF) exists that contains pipelines with activities that are dependent on database tables
The definition of a database table changes
The next time the pipeline runs it fails
Of course we can set up something so it fails gracefully but ...
I need to proactively execute a scheduled Powershell script that iterates through all ADFs (iterating is easy) to do the equivalent of the 'Validate All' (validating is impossible?) functionality that the GUI provides
I do realise that the Utopian CI/CD DevOps environment I dream about will one day in the next year or so achieve this via other ways
I need the automation validation method today - not in a year!
I've looked at what I think are all of the powershell cmdlets available and short of somehow deleting and redeploying each ADF (fraught with danger) I can't find a simple method to validate an Azure Data Factory via Powershell.
Thanks in advance
In the ".Net" SDK, each of the models has a "Validate()" method. I have not yet found anything similar in the Powershell commands.
In my experience, the (GUI) validation is not foolproof. Some things are only tested at runtime.
I know it has been a while and you said you didn't want the validation to work in an year - but after a couple of years we finally have both the Validate all and Export ARM template features from the Data Factory user experience via a publicly available npm package #microsoft/azure-data-factory-utilities. The full guidance can be found on this documentation.
According to the Microsoft documentation, you need to have Basic access in VSTS in order to create Test Plans, however, when I log in with a user having Basic access, the link for adding a Test Plan is not there.
What additional access does this user need to be able to create Test Plans? The user is also an administrator of the team to which Test Plans need to be added.
Screenshots showing the MS documentation, the particular user's access level, how it should look according to MS and how it does look (with the "+" icon to add Test Plans not appearing when logging in as the user in question with Basic access).
That article introduce the testing permission and access, not for the way (UI) to manage test (e.g. Create test plan)
With basic access level and Contributors permission, you can create test plan. There are many ways to create test plan, such as Microsoft Test Manager (client software), REST API. But you can’t do it in Test tab without Test Manager extension, which is used to manage test online (test tab).
To conclude, if you want to create test plan on online (test tab), you need to install Test manager extension. You can build a custom extension to manage test through calling REST API in order to manage test online without install Test manager extension.
The Test Manager module in VSTS requires additional license.
It costs $52 per month per user.
Also Visual Studio Enterprise subscription includes this license.
So, as you are using Basic license of VSTS the Test Manager module is not fully available, even with Administrator role.
I think it should be explained at documentation.
I found this link Test Plans, I hope can be useful for anyone.
Once I clicked on Azure DevOps Portal at Test Plans, it shows this label.
Upgrade to Test Manager extension to get full test management
capabilities Use the paid Test Manager extension to get access to
advanced test management capabilities like assign configurations,
assign testers, centralized parameters, authoring tests in grid view,
exporting test results etc. in your account. Learn more.
Test plans view
Complementing with Create a Test Plan.
I want to keep things as simple as possible and I don't want a complicated security mechanism. Basically I need for a user an ID and an e-mail address and I really don't want to bother about other things. Also, I was a minimum overhead in terms of security (if there is anoter provider who can do it for me, that's even better).
What is the simplest way to do this? I was thinking about incorporating LiveID or OpenID by I don't know what are the advantages/disadvantages.
I am working with the Azure SDK.
If you use the Windows Azure Access Control Service, you can basically outsource all identity management. Take a look at the Windows Azure Platform Training Kit - there's a lab called "Introduction to the AppFabric Access Control Service 2.0" that will get you up and running quickly. Currently, you can choose any combination of the following identity providers:
WS-Federation
Facebook
Windows Live ID
Google
Yahoo!
"Simple" for whom?
The simplest strategy for you would probably be to use ASP.NET's standard SQL-based authentication provider. You just run a script against your database to set up all the tables, and then you use ASP.NET's built-in utility methods to authenticate. Give your user-specific tables a foreign key reference to that user's ID, and you're good to go. We've done this, and never had any trouble with it. It's a tried and well-used system, so you know you won't be introducing any security invulnerabilities by hacking your own solution together. (see SqlMembershipProvider vs a custom solutions)
If you want something simple for the user, then an OpenId solution would be my pick. Set up something like StackOverflow has, where you can let users choose an account from a number of trusted providers to allow them to log in. From the user's perspective, it's really nice not to have to remember one more username and password for one more site.
Ideally, I'd like to use Azure table storage as the provider, but SQL Azure will also work. Anything I've dug up so far is over a year old, using deprecated approaches. I.e., outdated code samples, SDKs and IDEs.
As the title states, this would be applied to an MVC2 app running in Azure. Examples, code, links, etc. do not necessarily have to be for MVC. Anything related to a .Net 4.0 web app using Forms Authentication on Azure will do.
Microsoft originally released a set of sample providers with the PDC08 SDK - but these definitely are not recommended for commercial use.
Recently this project has produced some new ones - http://azureproviders.codeplex.com/ - I'd recommend going with that one as it is "live code" - you might also be able to contribute something back to it.
If you do use these providers, please be aware that Azure charges per transaction - at a base rate of $0.01 per 10000 transactions - and that the logic within these providers can cause "quite a few" transactions to occur. So if your site is busy and has a lot of membership activity, then it could work out quite expensive to operate.
If you are using SQL Azure membership, then the membership SQL is standard - http://support.microsoft.com/kb/2006191 - the only differences in the ASP SQL scripts is in the Session storage (since Session uses SQL Agent to clear sessions - and SQL agent is not supported on SQL Azure)
Personally, I've use the Table storage for test/demo sites - but for anything "real" I've moved towards SQL Azure - it's easier to query, to run reports, to backup, etc
Unfortunately, unless you role your own provider, the only sample I have seen is the outdated one you mentioned. For user authentication (RoleProvider), it is not too bad (i.e. no bugs I have heard about). However, for Session state, it has some issues. I don't think it does any sort of encryption however, so the passwords might be in plaintext. Worst case scenario, you could at least use it as starting point for your own.
A quick look around and I can't even find the 'Additional Samples' anymore. They might have been lost when Code Gallery did an update awhile back. I know it is still used in http://phluffyfotos.codeplex.com, so you could pull it from the source there at least.
I would not use ATS Forms authentication, because of transaction cost associated, if your site is going to have alot of authentication requests (even token authorization requires check against ATS)
I would use Forms Authentication against SQL Azure with standard SqlMembershipProvider
It works just fine. I've manually migrated necessary aspnet tables & stored procs over to SQL Azure from a local SQL server instance without problems. Just update the aspnet_schemaversions table to have this content:
common 1 1
membership 1 1
personalization 1 1
profile 1 1
role manager 1 1