If you missed the Day 1 recap you can find that here. Onto Day 2!
On the Job: Putting PowerShell Jobs to Work
Really great session here. I learned a lot about scheduled jobs, why you would want to use them, and how they are different from using Task Scheduler to run a scheduled job.
- Scheduled jobs are separate from the Windows Task Scheduler
- Found in Microsoft > Windows > PowerShell > ScheduledJobs folder in Task Scheduler
- Jeff mentioned that there is an open issue on Connect about using alternate credentials in Scheduled Jobs. I am pretty that issue is this one here.
- Jeff also mentioned that he has a Scheduled Jobs module. I tried to locate this but apparently my GoogleFu is not strong. If anyone has a link to it let me know and I will update this post.
- It is easier to unregister an existing job and re-register it than it is to modify the existing job
- Recommended to use a specific service account for every job
7 Secrets of CIM
Not a lot to say about this session. It was definitely interesting, but I didn’t take a lot of notes on it. I also think the title is misleading, because I wouldn’t say any of the stuff shown was a “secret”. We were also only able to get through 4 of the 7 “secrets” before we ran out of time.
- Mentioned Richard Siddaway’s book on PowerShell and WMI as a great learning resource. That can be found here.
- PowerShell help topic on About_Splatting which can be found here.
- Use as many filters and parameters as you can when querying WMI/CIM to help reduce the number of results
Hyper-V and WMI (When the Hyper-V Module is not enough)
This was a super interesting session that I also didn’t take a lot of notes on. It was really cool to see the Virtualization WMI namespaces and how that could be used with Hyper-V. It is certainly not anything I would have ever thought of one my own.
- In Server 2012 (and higher) the namespace is now root/virtualization/v2
- Anything less than Server 2012 the namespace is root/virtualization/v1
Everything you Always Wanted to Know About Implicit Remoting (But Were Afraid to Ask)
This seriously blew my mind. I had no idea how implicit remoting worked or what was even possible with it. Quick and dirty rundown of how it works.
- Create a new-pssession to a server with a module you need (think Active Directory)
- Load the module into the session
- Import-PsSession into the local session
- This allows commands to be run locally that are executed on the remote session
- This importing of the session is stored in a temporary module in PowerShell
- This session can then be exported to your PowerShell profile and used later
- Formatting files are not transferred locally as part of the import process
Working with System Center 2012 Orchestrator and Windows PowerShell
First, I want to give major props to Sean. He had quite the experience making it out to the PowerShell summit and did a great job with this presentation. This presentation was all about how to use PowerShell scripts inside Orchestrator runbooks.
- Using PowerShell inside Orchestrator can augment what Integration Packs are missing
- Basic process is to build a Runbook, create a script, add to .NET task in Runbook (PowerShell type), integrate Orchestrator variables as needed, publish or subscribe to the Orchestrator databus as needed
- No arrays allowed in PowerShell scripts in Orchestrator
- There is no Undo in Orchestrator! Make sure to check out your Runbooks, or better yet copy and paste them into a different editor to edit them in
- Actions -> Export Runbook is your friend!
- Running a PS Script in the Runbook Tester only will tell you there was an error, no real information
- Look on right side of Runbook Tester under Variables for issues with what Orchestrator thinks are “phantom variables”
- Sean has created a page with links to System Center 2012 Orchestrator Resources here.
- Also make sure to check out the Community SCORCH project on CodePlex here.
Empower Your Help Desk w/ PowerShell
This was another great presentation, and if you haven’t met him or seen him in person, he is very high energy. This centered on how to talk to your help desk about what they need, and how to create a GUI that gives the Help Desk what they need without overcomplicating things. Jason touched a lot on his experiences doing this and even demo’d a GUI he has been building that looked really nice.
- When talking to your Help Desk, remember that you have 2 ears and 1 mouth for a reason. Listen to what they are saying!
- Ask them what they need
- What information do they need?
At 4 PM members of the PowerShell DSC team came by and did a bunch of lightning demos about things they are working. Saw a lot of cool stuff, but far and away the highlight was using PowerShell Desired State Configuration to configure a Linux machine. Yes, this actually happened. I Saw it with my own eyes and could barely believe it. And if they can configure Linux using Desired State Configuration, I have some guesses about what is coming in the future and am super excited about the possibilities.