Together with our education partner Vijfhart we’re proud to announce that our colleagues Koen and Jeff will provide a 3-days hands-on and practical PowerShell training. This training is based on the ‘Learn PowerShell In A Month Of Lunches’-book and is intended for anyone willing to learn the language.
So, want to learn how to automate the boring stuff and elevate your skills (and possibly your career) to the next level? This training will definitely help you along that path.
NOT A MOC!!!
This training is NOT based on the Microsoft Official Curriculum, but on the ‘Learn PowerShell in a Month of Lunches’-book. The exercises during the training are based on Koen’s and Jeff’s experiences in the field over the last 10 years. Practical tasks and examples that will give you the knowledge needed to apply PowerShell in your daily work the moment you’ve finished the training. So, awesome for Ops-people, admins and engineers!
On the 18th of April, our colleague Rex will provide a Chocolatey workshop at Startel, one of our Education partners.
After completing this workshop, students will be introduced to:
* Simple and advanced scenarios for Chocolatey. You will see that Chocolatey can manage anything software-related when it comes to Windows. * General Chocolatey use. * General packaging. * Customizing package behavior at runtime (package parameters). * Extension packages. * Custom packaging templates. * Setting up an internal Chocolatey Server repository. * Adding and using internal repositories. * Reporting. * Advanced packaging techniques when installers are not friendly to automation.
With the introduction of the new Az PowerShell module, the merger of the Azure.* and AzureRM.* modules, comes a new way of connecting to Azure.
When we get a list of the available commands to do something with an AzAccount, you’ll end up with the following:
As you can see, there are now Connect-/Disconnect-AzAccount and Login-/Logout-AzAccount cmdlets. So if you want to connect to Azure and use PowerShell cmdlets to manage your environment, which one do you use?
If you use either Connect-AzAccount or Login-AzAccount, you’ll end up with the following message:
For this, one would require user interaction. Would that not negate the whole concept of automation?
One of our customers contacted me with the request if we could automate this. His idea was that we would write something that could read the url and code, utilize a browser and through that automate the login.
Although I love billing customers, I don’t like to bill them unnecessarily. I decided to educate them instead:
The solution is already available
The solution is simply by using the cmdlet the way it is intended to be used. For an interactive environment, you can simply go to that website and fill in the code. When you require the cmdlet to be used in an automated process / script, you can use the cmdlets’ parameters to tweak its behavior so that it works in automation
. If you look at help of the cmdlets, you’ll notice that it has quite a few parameters that you can use. Amongst those is the -Credential parameter:
But what if you’re using an account with Multi Factor Authentication?
Well, let me introduce you to Service Principals and Managed Identities. Service principals are non-interactive Azure accounts. Like other user accounts, their permissions are managed with Azure Active Directory. By granting a service principal only the permissions it needs, your automation scripts stay secure.
If you want to know how you can create Azure Service Pricipals, take a look here.
Next to the Service Principal, the Connect-AzAccount cmdlet also requires you to provide its application ID, sign-in credentials, and the tenant ID associate with it:
Manage identities are a subset of Service Principals, and have therefor the same constraints. They are assigned to resources that run in Azure. You can use them for sign-in, and acquire an app-only access token to access other resources. Managed identities are only available on resources running in an Azure cloud.
Have you ever ran into the hard-limit in Azure for the amount of tags allowed on asingle resource, or resource group even? When you work in a large organisation that wants to track everything this mightbe one of the things happening to you.
Each resource or resource group can have a
maximum of 15 tag name/value pairs
The tag name is limited to 512 characters
The tag value is limited to 256 characters.
For storage accounts, the tag name is limited to
128 characters, and the tag value is limited to 256 characters.
Tags can’t be applied to classic resources such
as Cloud Services.
can’t contain these characters: <, >, %, &, \, ?, /
So this means we can have a Maximum of 15 tag name/value pairs on a resource/resource group. This means if you want to tag for example: Owner, Team, Manager, CostCenter, Environment,BackupType, Expirationdate, MaintenanceWindow, etc. You will run out of those tags pretty quickly.
Luckily looking at the rest of the limitations: The tag value is limited to 256 characters! (that is a lot of characters!), and tag names cannot contain a few set of characters.
Since we don’t spot curly braces in the ‘cannotcontain’ list, why not start using JSON in as tag value’s to concatenate tags?
Op 6 oktober 2018 heeft Methos een gezellig bedrijfsuitje mogen beleven. De drie medewerkers, en hun partners, hebben zich ternauwernood weten te redden uit de Mission Impossible escaperoom in Scheveningen. Met nog 1,5 minuut te gaan is de wereld gered, en dit keer niet door automatisering!
Onze wereldverbeteraars hebben daarna wel verdiend genoten van een avond Tasty Comedy op de pier. Danny, bedankt voor het organiseren!