As you probably know, the Install-WindowsFeature (used to be Add-WindowsFeature; that’s now an alias to Install-) can add Windows roles and features from PowerShell. If your server doesn’t have the installer source on the local disk, then the cmdlet will default to grabbing it from Windows Update - a pain for disconnected servers. Install-WindowsFeature does offer a means of using an alternate local source (like a DVD or file server location), but using it can be a bit hinky. The cmdlet help indicates that you should point to a Windows image (WIM) file. That’ll work, but you can’t just provide the path of the WIM. You also need to put a wim:/ prefix on the front of the path, and a suffix that tells the thing which edition of Windows you’re working with, so that it grabs the right bits. For example, wim:/d:/sources/install.wim:4. That “4” is the suffix for Datacenter Edition, telling the installer to look at index 4 within the WIM for the necessary feature.
$computers = Get-ADComputer -filter * -searchBase "ou=test,dc=company,dc=pri" foreach ($computer in $computers) { write-host "computer $computer" $result = Do-Something -computername $computer Write-Host "$($result.property) and $($result.value)" } Would you ever consider that acceptable? Some folks might well say, “sure! if I was just testing this, throwing in those Write-Hosts is no big deal. Heck, even if I was the only one who was going to use this, Write-Host isn’t bad.” And the point I’m going to make doesn’t just apply to Write-Host. It applies to anytime when you’re doing something that you know breaks “best practices,” but you justify it because it’s “just for you” or because “it’s just for testing.” To wit: if you need your script to output some status or tracking information, as in the above, use Write-Verbose. Yes, Write-Verbose requires a script or function to have this at the top:
One of the most important tasks for the** **DBAs is to ensure that there is a maintenance plan to recover data from a given disaster.
Â
As a DBA we need to design a maintenance plan according to our scenario and business requirements. Do we want to be able to recover data at any point of time? How much data loss can we accept? All these questions and many more must be answered before designing the plan. In this post we will assume a basic daily full backup to keep our data safe, we will assume that there is a job performing full backups to our databases every day at midnight.
Once we have our pull server in place and we’re starting to create configurations, we need to set up our client nodes to be able to connect to the pull server and how we want the node to behave.
The Desired State Configuration agent included in Windows Management Framework 4 (or natively on Server 2012 R2 / Windows 8.1) is exposed through the Local Configuration Manager.
Well, it isn’t your enemy, of course, but it’s definitely a tricky little beast. Get-Content is quickly becoming my nemesis, because it’s sucking a lot of PowerShell newcomers into its insidious little trap. Actually, the real problem is that most newcomers don’t really understand that PowerShell is an object-oriented, rather than a text-oriented shell; they’re trying to treat Get-Content like the old Type command (and why not? type is an alias to Get-Content in PowerShell, isn’t it?), and failing. Worse, PowerShell has just enough under-the-hood smarts to make some things work, but not _everything. _ For example, this works to replace all instances of “t” with “x” in the file test.txt, outputting the result to new.txt:
One thing that’s often very confusing about PowerShell is the difference between the shell itself - what I’ll call the engine in this article - and the application that hosts the engine. You see, you as a human being can’t really interact directly with PowerShell’s engine. Instead, you need a host application that lets you do so. The standard console - PowerShell.exe - is one such host; the Integrated Script Environment (ISE) is another. Those hosts “spin up” a _runspace, _which is essentially an instance of the PowerShell engine. When you type a command and hit enter, the host creates a pipeline, jams your command into it, and then deals with the output. A number of standardized PowerShell commands actually require the host to implement some kind of command support. For example, most of the core Write- cmdlets actually depend upon the host to do something. Write-Verbose is a great example: The command causes the engine to spew text into the Verbose pipeline; the host is responsible for doing something with it. In the case of the console host, the Verbose text is displayed as yellow text (by default) preceded by the word “VERBOSE:”. When you develop a script using the ISE or the console (which behave pretty similarly for most of the core commands), you get used to your script behaving in a certain way. If you then move that script over to another host - perhaps a runbook automation system that runs PowerShell scripts by hosting the engine, rather than by launching PowerShell.exe - you may get entirely different behavior. Here’s a perfect example: most of the “built-in” variables you’re used to working with in the ISE or the console aren’t actually built into the _engine, _they’re built into those _hosts. _For example, since the host is responsible for presenting verbose output, the host is what creates and uses the $VerbosePreference variable. When your script is running in a different host, $VerbosePreference may not exist, and indeed verbose output may simply be ignored. An off-the-shelf PowerShell runspace doesn’t actually come with very much “built-in” at all, so scripts can behave very differently. It’s pretty important to understand these potential differences. When a developer sets out to create their own host application - like most of the commercial script editors do - it can be very confusing and frustrating, because they essentially have to reverse-engineer much of what the PowerShell.exe console application is doing, so that they can provide an equivalent experience. But you should never assume that a script’s behavior under one host will be consistent in all other hosts; test and verify.
Now that we have some of the basics down, we can start to look deeper at how composable these configurations are. A DSC configuration defined in PowerShell offers several advantages, not the least of which is that a configuration can be parameterized.
Now that’s a title! Â We’ve worked through my reasoning as to why I want Desired State Configuration (DSC) and how to build a pull server. Â Today and in the next post we are going to look at how to create configurations which describe how our target systems are supposed to work.
Configurations are the driving force for DSC. Â A configuration is a Managed Object Format (MOF) document that describes the how a specified server (or servers) should look.
Quick recap, I’m working through a series of posts about the Desired State Configuration infrastructure that I’m building at Stack Exchange, including some how-to’s.
I started with an overview of what and why. Â Today, I’m going to start the how.
Building a Pull Server
I’m going to describe how to do this with Server 2012 R2 RTM (NOTE: this is not the General Availability  release, so there may be changes at GA), since that’s the environment I’m working most in.  If there is enough demand, I may follow up with how to do this using the Windows Management Framework on downlevel operating systems after the GA version of WMF 4 is released. The first step is adding the required roles and features, including the DSC Service.
