Tag Archives: Microsoft

Meeting #17 – Handy PowerShell Profile Tips and Tricks


Description:

Your PowerShell profile is a convenient way to customize your environment and make your life easier. We’ll talk about the different profiles, ways to keep things in sync, along with custom aliases and functions to enable PowerShell laziness.

Speakers:

Damien Solodow is the Systems Engineer for Harrison College; a role that he has held for 6 years. He’s been working in IT since 1997, and has been managing Windows Servers since NT 4.0. Started working with PowerShell in Exchange 2010, and has since expanded to using it for Windows Server, Active Directory, VMware, Citrix XenApp and other items.

Agenda:

6:00 – 6:30 Food | Networking
6:30 – 6:45 Introduction | Announcements | Speaker Introduction
6:45 – 7:45 Presentation
7:45 – 8:00 Giveaways

Meeting #15 – Learning Windows PowerShell, Group Discussion


Description:

Let’s discuss the up’s and down’s of learning Windows PowerShell. Run into a hurdle? Great! Let’s share that information with everyone else. Find a really cool resource while learning? Fantastic, you should share that too! Throughout this group discuss we will have information to share; but at the same time we will be eliciting input from the audience. This is not going to be your normal presentation we are going to avoid PowerPoint as much as possible and make this a nice group activity.

Speakers:

Matt Griffin (MCT, MCSA, MCITP, MCTS, MCP) is a Technical Team Lead at Apparatus in Indianapolis, IN. Matt participates in multiple Technology based User Groups including the Indianapolis PowerShell User Group where he is the President. Over the last 5 years while Matt has worked in IT he has worked with many technologies ranging from Windows Server, SharePoint, Office 365 and his latest dive into Exchange Hybrid deployments. Matt’s primary focus in his IT career is automating every task possible to make management of hundreds if not thousands of systems easier.

Sam Spoerle is a Technology Analyst at Apparatus in Indianapolis, IN.

Garrett Ford is an Intern at Apparatus in Indianapolis, IN. Garrett is wrapping up his final semester at IUPUI this December and has just recently learned Windows PowerShell.

Nicholas Richardson is currently employed as a Windows System Administrator at IUPUI. As a young and upcoming IT Professional, he is focused on making the computing environment at IUPUI easy and efficient to use and manage. Currently, Nicholas has strong interests in PowerShell scripting, IT management, automating daily tasks, and developing tools that are used by other employees. Nicholas is a student at IUPUI working towards a Bachelor’s of Science in Computer Science. Nicholas is interested in learning all available facets of both the management and development spheres.

Agenda:

6:00 – 6:30 Food | Networking
6:30 – 6:45 Introduction | Announcements | Speaker Introduction
6:45 – 7:45 Presentation
7:45 – 8:00 Giveaways

June NoVa PowerShell User Group


The next meeting will be held June 26th at 7PM at the same location in Herndon.

This time, Marcus Fernandez from Microsoft will be showing us how to go from Zero to Azure VM Using PowerShell.

We will also go over some basic PowerShell best practices. Of course, if you have something you are working on and would like some help or just want to show it off, we’ll make some time for that as well.

Look forward to seeing you there,
— Chris

PhillyPoSH June 5th 2014


Meeting Info

Date: June 5th, 2014
Speaker: Jeff Hicks (blog | twitter | google+)
Speaker Topic: Getting Started with Desired State Configuration (DSC)

Registration
Please register if you plan to attend in person or online. The meeting URL to join us remotely will be included in your Eventbrite registration confirmation.

About Jeff
Jeffery Hicks is a multi-year Microsoft MVP in Windows PowerShell, Microsoft Certified Professional and an IT veteran with almost 25 years of experience, much of it spent as an IT infrastructure consultant specializing in Microsoft server technologies with an emphasis in automation and efficiency. He works today as an independent author, trainer and consultant. Jeff writes the popular Prof. PowerShell column for MPCMag.com, is a regular contributor to a variety on online sites, as well as frequent speaker at technology conferences and user groups.

Jeff’s latest books are Learn PowerShell 3 in a Month of LunchesLearn PowerShell Toolmaking in a Month of Lunches and PowerShell in Depth: An Administrators Guide.

You can keep up with Jeff at his blog http://jdhitsolutions.com/blog , on Twitter at twitter.com/jeffhicks and on Google Plus at http:/gplus.to/JeffHicks.

About PhillyPoSH
The Philadelphia PowerShell User Group (PhillyPoSH) is a group of IT Professionals interested in learning and using Windows PowerShell. We encourage PowerShell users of any skill level (from newbie to expert and everything in between) to join.

Meetings are held on the first Thursday of every month at the local Microsoft office in Malvern, PA. We usually have a quick discussion of community news and upcoming events, along with a 30-45 minute technical presentation. Presentations may run longer if we have a guest speaker, but otherwise we usually wrap with a Script Club, where we work together on a particular scripting problem to learn new skills and techniques!

Why “Puppet vs. DSC” isn’t Even a Thing


After all the DSC-related excitement this week, there have been a few online and Twitter-based discussions including Chef, Puppet, and similar solutions. Many of these discussions start off with a tone I suppose I should be used to: fanboy dissing. “Puppet already does this and is cross-platform! Why should I bother with DSC?” Those people, sadly, miss the point about as entirely as it’s possible to do.

Point 1: Coolness

First, what Microsoft has accomplished with DSC is cool. Star Wars Episode V was also cool. These facts do not prevent previous things – Puppet/Chef/etc and Episode IV – from being cool as well. Something new being cool does not make other things less cool. This shouldn’t be a discussion of, “Puppet did this first, so nothing else can possibly be interesting at the same time.” As IT professionals, we should be looking at everything with an eye toward what it does, and what new ideas it might offer than can be applied to existing approaches.

Point 2: Switching

Have you seen the magazine ads suggesting you ditch Puppet and start using DSC? No, you have not – and you will not. If Puppet/Chef/etc is meeting your needs, keep using it. The fact that Microsoft has introduced a technology that accomplishes similar things (make no mistake, they’re not the same and aren’t intended to be), doesn’t mean Microsoft is trying to convince you to change.

I know where people get confused on this, because in the past that’s exactly what Microsoft intended to do. They’re not, this time. And I’ll explain why in a minute.

Point 3: DSC on Linux

Snover demonstrated a DSC Local Configuration Manager running on Linux, consuming a standard DSC MOF file, being used to set up an Apache website on the server. The underlying DSC resources were native Linux code.

This is not an attempt to convince Linux people to switch to Windows, nor is it an attempt to convince them to use DSC. Saying so is like saying, “Microsoft made PowerShell accept forward slashes as path separators in an attempt to convert Linux people…. but we’re too smart for that, hahahahah!” It’s idiotic. Microsoft knows you’re not going to suddenly break down and switch operating systems. They may be a giant corporation that sometimes makes silly moves, but they’re not dumb.

No, DSC on Linux is for Windows admins who choose to use DSC, and who want to extend that skill set to other platforms they have to manage. People who aren’t, in other words, faced with a “switch” decision.

Point 4: Puppet/Chef/etc Should Use DSC

Linux is, in many many ways, a more simplistic OS than Windows. And I mean that in a very good way, not as a dig. Most config information comes form text files, and text files are ridiculously easy to edit. Getting a solution like Puppet to work on Linux is, form a purely technical perspective, pretty straightforward. Windows, on the other hand, is built around an enormous set of disparate APIs, meaning getting something like Chef/DSC/whatever working on Windows is not only harder, it’s essentially a never-ending task.

Microsoft is pouring time and money into creating DSC resources that can, through a very simple and consistent interface, configure tons of the OS. The coverage provided by DSC resources will continue to grow – exponentially, I suspect. That means Microsoft is doing a lot of work that you don’t have to.

Even if you’re using Puppet/Chef/etc instead of DSC, you can still piggyback on all the completely open and human-readable code that actually makes DSC work. Your recipes and modules can simply call those DSC resources directly. You’re not “using” DSC, but you’re snarfing its code, so that you don’t have to re-invent that wheel yourself. This should make Puppet/Chef people super-happy, because their lives got easier. Yes, you’ll doubtless have to write some custom stuff still, but “save me some work” should always be a good thing.

Point 5: Tool vs. Platform

Another thing that sidetracks these discussions is folks not understanding that Puppet/Chef/etc each provide a complete solution stack. They are a management console, they are a domain-specific language, and they are a platform-level implementation. When you adopt Puppet, you adopt it from top to bottom.

DSC isn’t like that.

DSC only provides the platform-level implementation. It doesn’t come with the management tools you actually need in a large environment, or even in many medium-sized environments. I completely expect tools like System Center Configuration Manager, or something, to provide the management-level tooling on top of DSC at some point – but we aren’t discussing System Center.

So arguing “Puppet vs. DSC” is a lot like arguing “Toyota vs. 6-cylinder engine.” The argument doesn’t make sense. Yes, at the end of the day, Puppet/Chef/etc and DSC are meant to accomplish every similar things, but DSC is only a piece of the picture, which leads to the most important point.

Point 6: Microsoft Did Something Neat

You can’t take your Puppet scripts and push them to a Chef agent, nor can you do the reverse. Puppet/Chef/etc are, as I mentioned, fully integrated stacks – and they’re proprietary stacks. “Proprietary” is not the same as “close-sourced;” and I realize that the languages used by these products aren’t specifically proprietary. But the Puppet agent only knows how to handle Puppet scripts, and the Chef agent only knows how to read Chef scripts. That’s not a dig at those products – being an integrated, proprietary stack isn’t a bad thing at all.

But it’s interesting that Microsoft took a different approach. Interesting in part because they’re usually the ones making fully-integrated stacks, where you can only use their technology if you fully embrace their entire product line. This time, Microsoft bucked the trend and didn’t go fully-integrated, proprietary stack. Microsoft did this, and the simple fact that they did is important, even if you don’t want to use any of their products.

From the top-down, that is from the management side down, Microsoft isn’t forcing you to use PowerShell. They’re not forcing you to use Microsoft technology at all, in fact. The configuration file that goes to a managed node is a static MOF file. That’s a plain-text file, as in “Management Object Format,” as in developed by the Distributed Management Task Force (DMTF). A vendor-neutral standard, in other words.

See, Microsoft isn’t pushing DSC as a fully integrated stack. DSC is just the bottom layer that accepts a configuration and implements it. Puppet Labs could absolutely design their product to turn Puppet scripts into the MOF file that DSC needs. You’d be able to completely leverage the OS-native, built-in configuration agent and all its resources, right from Puppet.

Frankly, de-coupling the administrative tooling from the underlying API should make people happy. If we’re having a really professional, non-fanboy discussion about declarative configuration, I think you have to admit that Microsoft has kinda done the right thing. In a perfect world, the Puppet/Chef/etc administrative tools would let you write your configuration scripts in their domain-specific language, and then compile those to a MOF. Everyone’s agents would accept the same kind of MOF, and execute the MOF using local, native resources. That approach means any OS could be managed by any tool. That’s cross-platform. You’d be free to switch tools anytime you wanted, because the underlying agents would all accept the same incoming language – MOF.

I’m not saying Puppet/Chef/etc should do that. But if you’re going to make an argument about cross-platform and vendor-agnostic tooling, Microsoft’s approach is the right one. They’ve implemented a service that accepts vendor-neutral configurations (MOF), and implements them using local, native resources. You can swap out the tooling layer anytime you want to. You don’t need to write PowerShell; you just need to produce a MOF.

At the End of the Day

I think the folks behind Puppet/Chef/etc totally “get” all this. I think you’re probably going to see them taking steps to better leverage the work MS is doing on DSC, simply because it saves them, and their users, work. And I don’t think you’re going to see Microsoft suggesting you ditch Puppet in favor of DSC. That’s a complete non-argument, and nobody at Microsoft even understands why people thing the company wants that.

I fully recognize that there’s a lot of “Microsoft vs. Linux” animosity in the world – the so-called “OS religions.” I’ve never understood that, and I certainly am not trying to convince anyone of the relative worth of one OS over another. PowerShell.org – a community dedicated to a Microsoft product – runs on a CentOS virtual machine, which should tell you something about my total lack of loyalty when it comes to choosing the right tool for a job. If you’re similarly “non-religious” about operating systems, I think DSC is worth taking a look at just to take a look at it. What’s it do differently? How can you leverage that in your existing world? Are there any approaches that might be worth considering?

Part of my frustration about the whole “Puppet vs DSC” meme is that it smacks of, “my toys are shinier than your toys,” which is just… well, literally childish. And it worries me that people are missing some of the above, very important, points – mainly, that Microsoft is trying really damn hard to play nicely with the other kids in the sandbox for a change. Encourage that attitude, because it benefits everyone.

Once More…

And again, I don’t think Microsoft is trying to convince you to use DSC, or any other MS product, here. I’m certainly not trying to do so. I think DSC presents an opportunity for folks who already have a declarative configuration management system, strictly in terms of saving you some work in custom module authoring. And I think for folks that don’t have a declarative configuration management solution, and who already have an investment in Microsoft’s platform, DSC is going to be an exceptionally critical technology to master. That doesn’t in any way diminish the accomplishment of the folks behind Puppet/Chef/etc. In fact, if nothing else, it further validates those products’ goals. And I think it’s massively interesting that Microsoft took an approach that is open to be used by those other products, rather than trying to make their own top-to-bottom stack. It’s a shift in Microsoft’s strategic thinking, if nothing else, and an explicit acknowledgement that the world is bigger than Redmond.

Let’s at least “cheers” for that shift in attitude.

 

 

 

 

Episode 268 – PowerScripting Podcast – Paul Long from Microsoft on Message Analyzer


A Podcast about Windows PowerShell. Listen:

In This Episode

Tonight on the PowerScripting Podcast, we talk to Paul Long from Microsoft about Message Analyzer

News

Interview

Guest – Paul Long

Links

 

Chatroom Highlights:

<ScriptingWife> http://www.amazon.com/Network-Monitoring-Analysis-Protocol-Troubleshooting/dp/0130264954/ref=sr_1_7?s=books&ie=UTF8&qid=1398390644&sr=1-7&keywords=network+monitoring

<halr9000> http://www.microsoft.com/en-us/download/details.aspx?id=40308

<halr9000> http://blogs.technet.com/b/messageanalyzer/

<halr9000> http://technet.microsoft.com/en-us/library/jj649776.aspx

<halr9000> http://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-71-Message-Analyzer-Part-1

<ScriptingWife> FYI Ed and I will be the guests for Singapore online meeting Friday night May 2nd 830 PM EST (Sat May 3rd Singapore time) sign up here http://www.eventbrite.sg/e/powerbreakfast-sg-01-tickets-10142282841?aff=eorg

<halr9000> ## you guys know this part

<stevenmurawski> ## Are there any good walk thrus with Message Analyzer?  The learning curve is pretty steep coming from Netmon or Wireshark.

<stevenmurawski> ## can you run captures on server core or or remote instances and analyze locally?

<stevenmurawski> ## Any analyzers for PowerShell remoting or CIM over WSMAN?

<Stuwee> ## halr9000, you need to stay close to the mic, you seem to fade alot.

<stevenmurawski> ## Is there an option to view info (with a filter) in realtime, (like the commandline version of wireshark or tcpdump)?

<Stuwee> ## What can you do with PSH and Message Analyzer?

 

The Question -

  • Super power: omniscient

Up Next: Paul Long from Microsoft talks about Message Analyzer!


message analyzer icon

This Thursday, we’re going to delve into Microsoft’s network capture and analysis tool: Message Analyzer. Paul Long is a tech evangelist at Microsoft, and he writes at the MessageAnalyzer blog.

Please join us at live.powerscripting.net at 9:30 PM EDT for the live discussion and chatroom!

Philadelphia Meeting – May 1st 2014


Join us Thursday, May 1st when Boe Prox will present on “Managing WSUS with Windows PowerShell”.

Managing WSUS with Windows PowerShell
Windows Server Update Services (WSUS) is an extremely useful enterprise patching solution from Microsoft that allows you to keep your systems up to date with various types of patches. Boe is going to show us how to hook into the API and generate your own reports, view the configuration of the server and the application and synchronization events as well as automate your approvals using PowerShell.

More about Boe:
Boe Prox is a Senior Windows System Administrator and has been using PowerShell since 2008. He is also a recipient of the Microsoft MVP award in Windows PowerShell. He is also a recipient of the Microsoft Community Contributor Award for 2011 and 2012 and is an Honorary Scripting Guy. He is a moderator on the Hey Scripting Guy forum and is active and in the Windows PowerShell forum as well. He was also a judge for the 2012 & 2013 Scripting Games as well as a coach for the 2013 Winter Scripting Games. His current projects are PoshPAIG, PoshWSUS, PoshEventUI and PoshChat, all available at Codeplex.

Boe has published a several articles for Microsoft’s Hey Scripting Guy! blog and the PowerShell Magazine as well as having 2 chapters on TCP Communication and WSUS in the PowerShell Deep Dives book.

Please register if you plan to attend in person or online. The meeting URL to join us remotely will be included in your Eventbrite registration confirmation.

Episode 266 – PowerScripting Podcast – Matt Wrock from Microsoft on BoxStarter


A Podcast about Windows PowerShell. Listen:

In This Episode

Tonight on the PowerScripting Podcast, we talk to Matt Wrock about BoxStarter

News

Interview

Guest – Matt Wrock

Links

 

Chatroom Highlights:

[22:43:30] <Jaykul> FWIW, my 2c: I think a “moderated” feed (where you just trust the core chocolatey team to review packages, instead of trusting all the authors) is the answer to “trust” — the idea being the core team says that yes, this module just downloads and installs “the real product” that it claims to.

<Jaykul> ## Have you heard rumors that chocolatey may move away from nuget?

<Jaykul> ## Are you involved in the chocolatey community at all?

<Jaykul> ## Are you (un)happy/neutral that Chocolatey has moved their lib/install folders to C:\ProgramData

<Jaykul> ## Are you (un)happy/neutral about the idea of expecting users to be “elevated” when running cinst?

<Jaykul> ## Does that mean boxstarter only works on machines that have access to the public internet?  <– I know it does, just want to bring it up

<Jaykul> ## What do you think about a “Moderated” feed like NuGet has for Microsoft

<Jaykul> ## Isn’t virus scanning the package mostly useless, since the package is just a script that downloads from the web? Would you guarantee that the install.ps1 can’t download anything without scanning it?

<Dave_Wyatt> ## Assuming that malicious code does make it into Chocolatey, what’s the response?  API keys revoked, packages taken offline, etc?  How fast would that happen?

<JonWalz> http://boxstarter.org/

<JonWalz> if you use LastPass check out this tool http://blog.lastpass.com/2014/04/lastpass-now-checks-if-your-sites-are.html

<halr9000> http://www.atlantaallergy.com/pollenCount.aspx

<halr9000> http://www.nwasthma.com/pollen/pollen-count

<halr9000> http://boxstarter.org/

<halr9000> http://runasradio.com/?nomobile=1&ShowNum=355

<halr9000> http://chocolatey.org/

<JonWalz> http://npe.codeplex.com/

<halr9000> Downloading SublimeText3 64 bit (http://c758482.r82.cf2.rackcdn.com/Sublime%20Text%20Build%203059%20×64%20Setup.exe

<JonWalz> http://www.myget.org/

<Jaykul> halr9000: http://c758482.r82.cf2.rackcdn.com/Sublime%20Text%202.0.2%20×64%20Setup.exe <– that’s the “official” download link.

<JonWalz> http://inedo.com/proget/overview

<Jaykul> Sorry, yeah, http://c758482.r82.cf2.rackcdn.com/Sublime%20Text%20Build%203059%20×64%20Setup.exe my point is that your url was the official one

<halr9000> http://boxstarter.org/WebLauncher

<Jaykul> http://www.boxstarter.org/VMIntegration

<halr9000> e.g. http://boxstarter.org/package/nr/firefox

<halr9000> http://boxstarter.org/package/nr/rickroll

<mwrock_> http://boxstarter.org/WebLauncher has links to the firefox and chrome click once extensions at the end of the page

<Jaykul> http://boxstarter.org/package/astley

The Question -

  • Superhero – Professor Time

Tonight, Nana from the PowerShell team talks DSC and more!


Tonight, we’re pleased to have Narayanan (Nana) Lakshmanan, Senior Development Lead from the PowerShell team at Microsoft on the show! One of our big areas to cover is going to be DSC, and what Microsoft has been doing with the out-of-band releases of DSC resources with the DSC Resource Kit, which is now up to 50 resources!

Meeting #12 – Taking on the World! One Exchange Server at a time… with PowerShell!


Description:

We have PowerShell on our side. Exchange Server was the starting point for PowerShell to be part of the larger vision of the tools.
In this session we will discuss how to automate routine tasks and target common situations encountered by Exchange Admins, or maybe even the accidental Exchange Admin.

Just like many good chefs and the recipes they have, we will venture into making out tools and skills better. Exploring the common and in some cases, hidden gems of PowerShell automation in a great environment like Exchange Server.

From creating recipients to managing services. From working with the services to monitoring and troubleshooting. The great adventure begins!

Speaker:

Enrique Lima (MCITP, MCPD, MCSE+I, MCP+SB, MCT, MCDBA, MCSD, MCAD, CCNA, CCNP, OCP, LCP, LCI, RHCE) has over 18 years of experience in training, application development, database development and management, IT solutions architecture, and project management. Enrique has participated as a speaker and technical learning guide at conferences such as SharePoint Conference 2012, TechEd USA (2004-2013). He was also invited to TechReady 7, 9, 10, 11, 12, 13, 16 and 17, an internal Microsoft conference, as a Subject Matter Expert (SME) in the fields of Windows Azure, Office 365, SQL Server, Platform Virtualization, Application Lifecycle Management/Team Foundation Server, SharePoint Technologies and Service Oriented Architecture.

Enrique has been involved in architecting and developing solutions that leverage the integration of SharePoint Technologies, Windows Azure, Office 365, BizTalk, Commerce Server, and Content Management Server with other Microsoft and non-Microsoft platforms. He has been active in providing guidance in developing and designing solutions that expand and extend those technologies. He actively participated with Microsoft to create material and develop a path to tell the Azure story to IT Professionals and promote Windows Azure beyond just a development platform, also was co-author for Microsoft Official Courseware on SharePoint 2010, Implementation and Configuration (MOC 10174A), was lead author for Microsoft Official Courseware on SQL Server 2005 High Availability Solutions (MOC 2788A), and lead author for Microsoft Official Courseware on Designing Commerce Server 2007 Solutions (50015A). Currently developing and creating new courseware for SharePoint 2013.

Enrique has written, developed, and presented numerous Microsoft and vendor-specific custom classes. As a member of Microsoft’s Global Learning Services, he delivered training and consulting to clients in Latin America, Europe, and Asia.

Enrique’s academic background includes a Bachelor’s of Science, an Electronics Engineering degree, and a Masters of Business Administration from Universidad Francisco Marroquin, Guatemala.  He can be found on twitter on @enriquelima or his blog: http://geekswithblogs.net/enriquelima.

Agenda:

6:00 – 6:30 Food | Networking
6:30 – 6:45 Introduction | Announcements | Speaker Introduction
6:45 – 7:45 Presentation
7:45 – 8:00 Giveaways

The DSC Conversation Continues


Some lovely conversation on DSC over on Reddit… with some I wanted to perhaps offer an opinion on. From what I’ve seen, these are very common sentiments, and they definitely deserve… not argument or disagreement, but perhaps an alternate viewpoint. I’m not suggesting the commenters are wrong – but that maybe they’re not considering the entire picture.

Certainly if you work with a superset of MS OSs (i.e. you do Linux also), then Puppet or something like it seems like a no brainer. In fact, that is what we’re doing now. Puppet has powershell modules you can install for instance. Personally, I still feel like Powershell is overrated except for small snippets of that’s how something is exposed. Puppet can run powershell commands. AutoIT can run powershell commands… I just don’t see value in Powershell today.

The point is that, until PowerShell, there were no PowerShell commands. Microsoft was incredibly inconsistent about providing automation-friendly commands of any kind. They could have gone down the path of building command-line tools for Cmd.exe; they didn’t. The point of PowerShell is that Microsoft forced themselves to build commands. Now, if you run those from AutoIt, or Puppet, or whatever else – that’s cool. PowerShell is an API, not a tool. Whatever tool you use to access that API is just dandy. Without the API, the tools are useless.

As to DSC – I’m really confused. Why is this separate from Group Policy again? Why is it better? Or is MS giving up on Group Policy as needing a total re-write?

The advantage of Group Policy over DSC, today, is that GP has richer ability to target computers based on OU membership, WMI criteria, etc. Today, DSC targeting isn’t that flexible. On the other hand, GP is extremely difficult to extend, since client extensions are native code. GP was built to manage the registry, although it’s been extended to do more. DSC is built to do whatever PowerShell (and, via CIM, native code) can touch. My opinion? Yeah, DSC will obviate GP over time. Not instantly.

Specifically, as I’ve been rolling out Puppet across Windows and Linux, I see that in some ways, it brings the computer GPO aspect to Linux, and duplicates it a bit on Windows.
Anyway, I won’t be surprised to see someone start writing DSC modules in Puppet, because you’ll want your config management to work across your platforms. And MS is kind of late to the game here – many many people have lots of knowledge already in Puppet, Chef etc…

The guys on the PowerShell team love Chef and Puppet. I think you’re confusing “api” and “tool.” There are two pieces to DSC: Piece one is the ability of PowerShell to read a configuration script and produce a MOF. Piece two is the ability of a Windows computer to receive that MOF and reconfigure itself accordingly. Any tool can do piece one. Use Puppet to produce the MOF. Use Puppet to control which MOFs get sent where. That’s the intent. But Microsoft takes a big burden off the Puppet developers by having Windows know what to do with the MOF. Yeah, MS is late to the game. No question. But they’re joining the game, not reinventing it. What they’re doing works with what everyone else is already doing.

I would personally carry the sentiment even further and say that investing the bulk of your effort in DSC over something like Puppet would be needlessly tying your own hands. Why focus on something that’s platform specific when there is a good cross-platform alternative. Don’t put all your eggs in one basket as it were.

Wrong. It isn’t an either-or thing. DSC’s introduction at TechEd 2013 included a demo of Puppet (or was it Chef?) being used to send configurations to Windows – much more easily, because with DSC, Windows natively knew what to do with them. If you’ve got tooling like Puppet, use it. DSC is just making Windows work better with it. The whole point of DSC is that it plays the cross-platform game everyone else has already been playing. 

Purely on the Windows side, the need to focus on DSC is more about developing the DSC resources you need, so that you can send a MOF (from Puppet, say) to a Windows computer, and that Windows computer will know how to configure everything you need configured. Microsoft will continue to produce resources for core OS and server application stuff; any LOB stuff is what you’d be focusing on.

Heck, even in a pure-Windows environment, with cross-platform off the table, Puppet provides tooling that DSC does not. You’re going to need those tools, whether it’s Puppet, some future System Center thing, or whatever. DSC is a mid-level API, not a tool.

Configuration managment does seem to be the future — I just don’t agree completely with the author’s point of a view that it will have to be DSC.

On Windows, DSC will be the underlying API that your configuration management tool talks to. DSC isn’t a configuration management tool. DSC bridges the gap between a text-based MOF and the bajillion proprietary protocols MS uses internally in their products. Remember, on Linux, it’s easier – everything already lives in a text file of some kind, right (oversimplifying, I know, but still)? In Windows, config information lives everyplace; DSC’s main job is to bridge the gap. DSC doesn’t provide management of what configuration goes where; it just provides the implementation mechanism. In PowerShell, there’s a primitive ability to write configurations, because MS has to give you something, but yeah… I think most organizations would benefit from good tooling atop that.

I think this entire discussion is why more people need to start learning (not necessarily using) DSC if you have Windows in your environment. Find out what it is, what it isn’t, and how it’ll play into the other efforts you’ve got underway. There’s a ton of misconception about what it is and where it’s meant to fit in. When I say, “if you’re not learning DSC, you’re screwed,” I don’t mean, “if you’re not using DSC.” I mean learning. Because if you’re not learning it, you’re going to be subject to the same misconceptions about it. You end up spending a lot of time reinventing what it’s willing to do – and what it’s willing to do in conjunction with your existing tools.

 

 

Free eBook from Microsoft’s Scripting Guy: Windows PowerShell Networking Guide


Ed Wilson, Microsoft’s Scripting Guy, has created a free ebook, Windows PowerShell Networking Guide. It’s designed to provide a super-quick PowerShell crash course, and then show you how to  manage various networking scenarios by using the shell.

And it’s free! Just click the link to get your copy – and please, tell a friend!

PoshNetworking.pdf