One of the coolest features of PowerShell is the many tools we have available to work with services on the web, be they SOAP, REST, RPC or even WSDL services. It’s no question, PowerShell makes it very easy to pull down data from any of these places.
Unfortunately, getting data from a service isn’t always as easy as embedding your credentials in a URL. In fact, some services require us to authenticate and ask the user for permission before giving up the goods. For these, oAuth is the de-facto standard for delegated access.
This is my first post here at PowerShell.org, and I have a goal of posting tips, tricks, articles, and solutions once a week. My first exposure to scripting was on my x486 computer. I would always create .bat files to launch my DOS based games from the root folder. I learned complex scripting through the use of VB Script, automating the roll out and updating of Windows 2000 desktops and servers. I quickly transitioned to PowerShell as my preferred scripting language upon its release. I use PowerShell on a daily basis to administer Windows Server, SQL Server, Exchange, Lync / Skype for Business, Citrix XenApp / XenDesktop, Office 365, and Dell Active Roles Server. I have very much enjoyed watching the progression and adoption of PowerShell as the default scripting language. I hope my posts will be useful to other administrators around the world.
Here’s a brief rundown of how we leverage a few Cmdlets from the PSScheduledJob module to manage our Analytics stack. For those of us on the Analytics team at
Pluralsight
, PowerShell is the lynch-pin which binds our two worlds together. To manage the gaps inherent in all platforms (since one tool would be hard-pressed to cover all areas), we use PowerShell to link the worlds of Data and Analytics (and back). We do this because of its depth and the ease with which we can automate just about anything.
I sat down last night my brain all fried and tried to compile a list of things to remember from the past week.
There is much focus on “changing the mindset” of the community. Get into the DevOps mindset and become a toolmakers. This is my take-home from the conference. There’s no way to summarize all of the conference other than to say: Look forward to the videos on YouTube.
Automation is awesome, but what if you need to run a script with elevated privileges? If you are following security best practices then the account you login with most likely doesn’t have the required elevated privileges. Storing your password in plain text in your scripts is no good either. So what do we do? There are several options and each has there place, but I’ll show you my favorite below. Check out the full article by clicking on the link below. While you are there check out some of my other posts, the script repository and the resource page.
Everyone who has managed Active Directory knows that keeping it free of “stale” accounts is a tough task. Typically no one cares about this until it’s time for the Microsoft True Up. Then we’ve got to hustle to get rid of all these unused accounts before we have to pay for them again! Pre-PowerShell it was tough because well… you didn’t have POWERSHELL! Now the hardest part about finding these accounts is defining what stale means to your company. There is no right or wrong answer to this question, but there are some things that we can check to help lead us to an optimal answer. You can read the rest of this article by clicking on the link below. While you are there check out some of my other posts, the script repository and the resource page.
So I wrote them an email and this was their reply:
————————–
“Hi Jonas – The “limited preview” designation on the PowerShell Gallery is because we are doing significant development to the site. * However, there is nothing about that status which should prevent you from sharing your code. *
If you look at DevOps as a means of removing hurdles between coders and users, there’s almost no better real-world, practical example than Amazon Elastic Beanstalk. If you’re not familiar with EBS, look into it - it’s kinda cool.
EBS isn’t suitable for every situation, to be sure. It’s mainly useful for Linux VMs, running Web sites, in fact, which isn’t 100% of your workloads. But the idea is pretty awesome. Developers store their code in a source control repo - ideally, Git. Along with their code - and this is the cool bit - they include a configuration file. This file can list things like environment variables, packages (installed from repos using NPM, RHL, YUM, etc), and so on.
Hello, PowerShell people! I’ve never posted on PowerShell.org before and so I feel as though I owe you a quick introduction before we dive into the tip I’d like to share with you.
My name is Thomas Rayner and I am a Microsoft MVP for Windows PowerShell. I’m also a systems administrator and degree program instructor. I volunteer a fair bit of time as the President of the Edmonton Microsoft User Group (EMUG). EMUG has a more in depth bio for me on their About Executive page in case you want to know more about the person behind the avatar. If you’re in the Edmonton area, I strongly recommend signing up for our mailing list so you can come attend the great events we put on.
If you’ve been a sys admin for more than a week you’ve probably heard this…“I’m locked-out, help!”. Normally the user has made their way to your cube and is impatiently tapping their foot waiting for you to magically solve there problem. So you find their account, reset their password and everything is right with the world…Or is it? Two minutes later they show up again because their account was locked-out before they even got back to their desk. Now what do you do?
