PowerShell automation Security scripting Microsoft Exchange Active Directory Migration VMware
Evgenij has been working with computers since the age of 5 and delivering IT solutions for the best part of the last 25 years. His Active Directory and Exchange background naturally led to PowerShell, of which he's been an avid user and proponent since its first release.
Evgenij is an active community lead at home in Berlin, a leading contrinutor to the German TechNet forum and an experienced user group and conference speaker.
Evgenij ist ein IT-Industrie-Veteran mit mehr als 25 Jahren Erfahrung im Gepäck. Seine Expertise liegt primär in den Microsoft- und VMware-Technologien. Die Beschäftigung mit Active Directory und Exchange führte zu PowerShell, und diese Technologie ist aus Evgenijs Blogbeiträgen, Artikeln und Konferenz-Vorträgen seit vielen Jahren nicht mehr wegzudenken.
Evgenij ist aktiv im TechNet-Forum sowie in den Offline-Communities: Er ist Group Lead für drei offizielle Microsoft User Groups in Berlin.
This is a compressed version of the two-part real-world data gathering workshop. We will look at some epic failures of scripts that look OK and work well in a small environment, then explore some routes of action to deal with huge amounts of data coming in from real-world scale sources like Active Directory, SQL or log stash.
This is not (primarily) about PowerShell multi-threading but rather about really knowing the idiosyncrasies of data sources like Active Directory or IoT streams and scripting practices that allow for mitigating those from the very beginning.
Scripts that access external data sources - flat files, Active Directory, IoT streams or relational databases - usually do so very well in the lab but will fail or take aeons to complete when facing real world scale. In this session, we explore information gathering techniques for large scale infrastructure data and produce recipes for your everyday automation.
In Part One we shall look at Active Directory, VMware vSphere and SQL, with an aside to SQLite.
This is a more workshoppy version of the Real-World Scale talk, with much more audience interaction intended.
Scripts that access external data sources - flat files, directories, databases or the Internet - usually do so very well in the lab but will often fail or take aeons to complete when facing real world scale. In this session, we explore information gathering techniques for large scale infrastructure data and produce recipes for your everyday automation.
In Part Two, we shall look more closely at file systems and flat structured data files, Internet resources, Event Logs and IoT data streams.
Part Two can, but need not necessarily be scheduled after Part One, should the selection committee decide to accept both parts. There is a compressed version of this talk which I also submitted.
The last public IPv4 addresses were allocated by the RIPE-NCC on the 25th Nov 2019. This is certain to speed up (or rekindle) discussion in many organizations about moving into the IPv6 address space. Are you prepared for this?
Maybe you Like to think that the ensuing changes mostly affect netwoking people. Well, think again. The move to IPv6 changes many of the infrastructure management paradigms, and so your scripting practice probably will have to change as well - starting with validation routines and all the way to having to support 4-to-6 transition technologies.
After this session, you'll know what parts of your scripts, modules and environments to look at in regard to IPv6, where the pitfalls lie and what you can do about it.
Everybody will agree that any script worth executing needs logging of some kind. In fact, many organisations require that logging be implemented in any script that gets to run in production.
This session is not going to be about *how* script logging can and should be done. Instead, we will look at what the logging is supposed to be for and how to actually extract the most value from it.
The answers to those questions will naturally lead to reevaluating some of the logging practices that have been common among us scripters for a very long time. Or maybe they won't, but the decision to keep things as they are will be a better-informed one.
If you ever have written a script that must run on a variety of systems but needs to connect to external resources using the same set of credentials, you probably know the pain of providing those credentials to the script in a secure, portable and cross-platform way. The Secret(s)Management module from Microsoft goes a long way towards achieving that goal but it’s not yet fully there, and the plug-in for connecting to a secrets vault of your choice may or may not be available for all OS platforms your script has to run on. With the XPCM module (there are actually two of them) I am providing an alternate approach to storing and retrieving secrets that can usually be implemented with zero maintenance on the endpoint running the script, even if the secret (i.e. password) changes on a regualr basis. The objective is to provide an identical experience on Windows and Linux (which, in theory, should cover MacOS as well), for every version of PowerShell that can be found on a supported system (2.0 through 5.1 and 6.0 through 7.1). In this talk I will present the rationale behind developing XPCM, the overall concept behind it and some of the unexpected hurdles I have encountered while developing and refining it.
1 Jun - 4 Jun 2020
Hannover, Lower Saxony, Germany