Explore articles and content from this author
372 articles published
Credentials suck. You obviously don’t want to hardcode domain credentials into a script - and PowerShell actually makes it a bit difficult to do so, for good reason. On the other hand, you sometimes _need_ a script to do something using alternate credentials, and you don’t necessarily want the runner of the script to know those credentials. So how do you deal with it? Let’s be clear: This is not a wish list.
PowerShell.org is going to be launching TechSessions this Fall. These will be ~1 hour online webinars, which you’re welcome to attend live. We’ll also record them and make the recordings available. In most cases you will need to register for each one, so that we can send the appropriate invite information. Our sponsors are working with us on these, so each one might be in a different webinar platform (Lync, Webex, etc) depending on who is providing the infrastructure that month.
As you may know, we’re in the process of putting together a PowerShell Summit Europe for Fall 2014. It’s a big task, with a lot of financial risks, so we try to get it right. Folks have been helpful on Twitter in offering city selection ideas… but there’s a bit more involved than just tossing out a city name. With that, here is the selection criteria! Given the information below… AND the fact that Germany/UK/Netherlands (in that order) have been getting the overwhelming majority of “in what cities would you attend the Summit” votes… what cities would YOU recommend we consider?
Take a look at this: `# version 1 Get-Content computers.txt | ForEach-Object { $os = Get-WmiObject Win32_OperatingSystem -comp $_ $bios = Get-WmiObject Win32_BIOS -comp $_ $props = @{computername=$_; osversion=$os.version; biosserial=$bios.serialnumber} New-Object PSObject -Prop $props } version 2 $computers = Get-Content computers.txt foreach ($computer in $computers) { $os = Get-WmiObject Win32_OperatingSystem -comp $computer $bios = Get-WmiObject Win32_BIOS -comp $computer $props = @{computername=$computer; osversion=$os.version; biosserial=$bios.serialnumber} New-Object PSObject -Prop $props } `These two snippets do the same thing.
I have received a lot of interest in a PowerShell Summit Europe, and we are starting to look at doing one in 2014. I know that’s a long way off, but it takes time to put these together when everyone’s volunteering that time! I have put together a very short survey to see if there is any consensus on where such an event might be held. The survey is online now and ready for your opinions.
Here’s an age-old debate that we can finally, perhaps, put an end to: The backtick character for line continuation. The basic concept looks like this: Get-WmiObject -Class Win32_BIOS -ComputerName whatever -Filter "something='else'"This trick relies on the fact that the backtick (grave accent) is PowerShell’s escape character. In this case, it’s escaping the carriage return, turning it from a logical end-of-line marker into a literal carriage return. It makes commands with a lot of parameters easier to read, since you can line up the parameters as I’ve done.
I’ve been working with a couple of folks lately who’ve been trying to review and pilot Active Directory auditing solutions. Both bemoaned the fact that, unlike consumer products of nearly any kind, IT products (specifically, enterprise software in this instance), don’t really get reviews from the admins who use those products. So, I’m curious. If you could (a) anonymously, and (b) without giving your organization’s name, would you (c) leave reviews of enterprise software for other admins?
Today, Brad Anderson (Corporate VP in the Windows Server/System Center unit) posted the first in what should be a series of “What’s New in 2012 R2” articles. In it, Anderson focuses on how Microsoft squeezed so many features into the 2012R2 release in such a short period of time. The short answer, which has been stated by Jeffrey Snover before, is “we build for the cloud first.” That means features we’re getting in 2012R2 have, for the most part, already been developed, deployed, and in use in some of Microsoft’s own cloud services.
I’m informed that sometime today Microsoft will be posting fixed core cmdlet help files for your downloading pleasure - so it’s safe to run Update-Help again, and you should definitely do so. There are likely a lot of fixes and improvements to the help text, and you won’t be “losing” the parameter value type information from the SYNTAX section. Maybe schedule an Update-Help for tomorrow morning? BTW - kudos to the team at Microsoft for getting this issue fixed so quickly.
Here’s an easy, low-stakes debate: How do you like to format your scripting constructs? And, more importantly, why do you like your method? For example, I tend to do this: `If ($this -eq $that) { do this } else { do this } `I do so out of long habit with C-like syntax, and because when I’m teaching this helps me keep more information on the screen. However, some folks prefer this: