This works fine for Windows Vista/Windows 2008 and above.
Earlier versions of Windows mis-report the number of processors ““ it counts the number of logical processors reports it as the number of physical processors.
Win32_Processor has the same problem on Windows 2003 and below.
There is a hotfix available from http://support.microsoft.com/kb/932370 that will correct the behaviour of these two WMI classes so that they report correctly
A question on my blog asked how do you know which domain controller you are running against when you search Active Directory. Unless you explicitly instruct your script to use a specific domain controller it will use the one to which you authenticated.
You can find the DC to which you authenticated with this simple function
function get-logonserver{ $env:LOGONSERVER -replace “\”, "" }
Microsoft’s a big company, and that makes it a big target for lawsuits. We all know that. But what doesn’t always sink in is how careful the company has to be. For example, in Microsoft Official Curriculum course 10961, Automating Administration with Windows PowerShell 3.0, I have to type Windows PowerShell every single time. I’ve actually been using “the shell” a lot, just to break things up a bit. We all casually refer to the shell as PowerShell, but Microsoft never does. Their trademark is on Windows PowerShell, and believe it or not someone has a trademark on PowerShell. I think it’s a sporting equipment manufacturer. As I’m writing the course, I started using Windows PowerShell on first reference, and then naturally - for me, at least - used just PowerShell from then on. Nope. Had to go fix ’em all. Weird, huh? I mean, technically… legally… you don’t trademark an entire word. You trademark it for use in a particular field. So it’s theoretically possible for Microsoft to own the trademark PowerShell in the world of computer software, and another company to own the same trademark for making backpacks or ski boots or whatever. But… I get it. You gotta be careful, and it’s easier just to not overlap with someone else’s trademark. Maybe they should have named it FrabulouShellâ„¢ instead, just to be really sure.
A question on the forum about a function had me thinking. The user had defined two parameters for the function and then used Read-Host to get the values.
NO
Much better way is to use an advanced function and make the parameters mandatory
`function
Getuserdetails
{
[
CmdletBinding
(
)
]
param
(
[
parameter
(
Mandatory
=
$true
)
]
[string]
$Givenname
,
[
parameter
(
Mandatory
=
$true
)
]
[string]
$Surname
)
Get-ADUser
-properties
telephonenumber
,
office
-Filter
{
(
GivenName
-eq
$Givenname
)
-and
(
Surname
-eq
$Surname
)
}
}
`If you call the function and don"™t give values for the parameters you will be prompted for them
I"™ve written a series of articles on PowerShell workflows that are appearing on the Scripting Guy blog. The first two in the series have been published at:
Microsoft course 10961, which will be a 5-day course on PowerShell 3.0, is officially in development! We received signoff on the outline this week, and I’ve submitted a first module for review. A big part of that review is making sure I’m using the template properly, as the authoring tool is fairly complex. It does, however, offer (more-or-less) one-touch publishing of the student manual, instructor slide deck, OneNote trainer pack, Lab Answer Key, and other documents, so it’s worth a bit of complexity. The outline process, along with the actual details of the writing, has been challenging. I pored through the feedback for 10325A, and the only consistent thing I took away was a general feeling that students and instructors worldwide are really, really different! Some European instructors cautioned against running class longer than 3 or 4pm. US instructors pointed out that a short day ending at 3pm often left students feeling shortchanged. Er. To try and accommodate both crowds, most days in 10961A will end in a significant lab, letting folks kind of free-form the end of the day however they want. Many folks pointed out that they liked to get into variables early in the course, not so much for scripting purposes but to simplify command-line stuff. Other instructors suggested I avoid variables too early, since they created the impression of a programming course, which scared off some students. Again… er. So I’m officially waffling on that one: I don’t formally cover variables until fairly late in the course (well, midway), but I introduce them quite early. It means students can potentially see and use variables on day 1, although I don’t get into all the details about how they work, naming rules, and so on. The way I’m writing them in, instructors also have the option to just gloss over them or skip them entirely if their students aren’t ready. I asked a few MCTs to look over some of my draft material and give me a delivery time estimate. I had pacing ranging from 2 minutes per slide to almost 8. Er. So I’m going with fairly simple slides that have minimal bullets (always, in most folks’ opinion, the right thing to do). Instructors can then decide how deeply they’ll cover the material based on their class’ needs. It does mean the instructor will need to be familiar with the material in advance - this will be a tough course to just pick up and teach ad-hoc. As, I believe, it should be. If there’s a theme here, it’s that you need a good instructor teaching you. As a courseware author, all I can really do is provide raw material, and an instructional design that leads most students through a sensible learning progression. But the instructor’s value-add is to be able to switch things up to meet the specific needs of their class. Every time an instructor tells me, “oh, I always move Module 11 to the second day of class,” I don’t take it as a sign of bad instructional design - I take it as the sign of a good instructor who hopefully is making the change to benefit his class. But classes vary widely, and I kind of have to write for the worst-case scenario. That can sometimes make a course seem overly timid - but that’s why the instructor is there, to add their own value, experience, examples, and demonstrations to further instruct and clarify. So the one thing I’m keeping in mind as I write 10961 is to leave room for the instructor to shine. Don’t fill the course so full of information that the instructor has no wiggle room. Give the instructor the ability to go slowly and less deep for classes that need it, and to go faster and deeper for classes that need that. Provide instructors with notes on what can be skipped if necessary, and what’s absolutely critical, so that they can triage. I’ll be doing a prep video to help provide even more context to instructors in that regard, and to let them know that customizing the delivery is absolutely okay, provided they’re doing so with an understanding of the original instructional design. Fingers crossed.
In September 2012, we incorporated PowerShell.org, Inc., and founded PowerShell.org. Our goal was to provide a solid Q&A forum, and to act as a portal to the rest of the PowerShell community. By any measure, we’ve had a great first showing. We have more than a dozen shareholders in PowerShell.org, Inc., making this the first community-owned PowerShell organization ever. We’ve signed on three Platinum sponsors - CBT Nuggets, SAPIEN Technologies, and Interface Technical Training. We’re now funded for 2-3 years of operation, including providing (upon request), gift cards to help local user groups pay for pizza and other monthly meeting expenses. PowerShell.org is now taking an average of 18,000 visits per month from more than 12,000 unique visitors, with a total of almost 57,000 monthly page views. Our forums have helped more than 760 people answer more than 850 questions. Microsoft’s Scripting Guy, Ed Wilson, has handed off the Scripting Games for 2013, and we’re preparing for a small-scale “Winter Scripting Camp” trial run that will include a purpose-built platform for reviewing events, submitting entries, and judging. And by the looks of things, that platform will run on PowerShell itself. We’ve announced our first PowerShell Summit North America, and have completely sold out. We’re already doing initial planning for 2014, aiming for a larger venue and hoping to accommodate twice as many attendees, and to fully cover speaker travel expenses. We’ve launched PowerShell People, accessible via PowerShell.net, where you can write a PowerShell script to create and post your own profile and “brag” page about your PowerShell activities and accomplishments. We’ve launched three free PowerShell.org-branded ebooks, and are preparing to launch our PowerShell.org TechLettermonthly (!!!) e-mail newsletter complete with feature articles, news updates, and more. That’s by (free) subscription only, so sign up if you haven’t done so already! We’ve also had help from Jason Hofferle on our new Books page, rounding up all the free and commercial PowerShell books out there. It’s been a whirlwind year, and it’s all thanks to you for supporting it. By asking questions in the forums, offering answers, creating your People page, registering for the Summit, signing up for the Newsletter - all of these little activities spur us all on to new heights, and we appreciate all the feedback you’ve offered. There will be more to come - follow the community on Twitter (and the Summit too, while you’re at it) for the latest announcements.If you’d like to contribute, just drop a note in the Suggestion Box forum - whether you want to help monitor a discussion forum, write book reviews, or whatever, there’s always room to contribute. There have been some setbacks. Will Steele, who had volunteered to populate our Events page, has had to step down due to health problems. Will has been a great contributor to the site and to the overall community, and we miss him. Our thoughts are with him and his family this holiday season. As we all wind down and look forward to the New Year, I wanted to personally express my gratitude to everyone who’s helped make all of this happen. Happy Holidays, Happy New Year, and I’ll see you again in 2013! Don Jones President and CEO, PowerShell.org, Inc.
As I write this, we’re close to sign-off on the outline of 10961A, which is a new 5-day Microsoft course on PowerShell v3. I sat down yesterday and starting doing some detailed-level design work on the proposed Module 9, which will cover PowerShell Remoting. I love Remoting (and yes, I capitalize the “R” when referring to the specific feature, much as I would for Workflow). And although I’ve taught Remoting over and over and over since it was introduced in v2, although with this course I’m trying something a bit new. I’m going to start by covering the basics: What Remoting is, what WS-MAN is (and yes, I know it’s formally called WS-Management, but you never see it referred to that way in-product), what WinRM is, and so on. I cover Invoke-Command and Enter-PSSession. Then I get into some advanced stuff, primarily covering how to pass arguments to Invoke-Command via its -ArgumentList parameter and an in-scriptblock Param() block. Surprisingly, this isn’t covered in the examples of Invoke-Command in the help. I was shocked to discover that. I need to use that technique in Module 10, so I’m covering it in 9. Then I get into sessions, and I also cover disconnected sessions. Then the cool begins. I cover both implicit remoting (which is tons easier to do in v3) and delegated administration via custom session configurations (also vastly easier in v3). In the penultimate lab for the module, students will create a Remoting endpoint that contains a single command (Set-ADAccountPassword), have that command run under Domain Admin credentials, and restrict the endpoint to members of a HelpDesk domain user group. Voila, delegated administration! We don’t go so far as to build a GUI tool atop it all, but that would be out of scope for this course. As-is, the lab covers an extremely real-world use of PowerShell and Remoting, and does it in a very practical and production-ready way. I think it’s gonna be awesome.
