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. Comments like, “I wish PowerShell could do ____” aren’t valid. What do you do using the technology as it exists today? Do you prompt for a credential and assume the script user will have it? Do you try to hardcode it? Do you set up a constrained endpoint? What? [boilerplate greatdebate]
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. In all cases, we’ll announce the TechSession in our TechLetter Newsletter, via banners on this site, and in a blog post. You’ll notice a new “TechSessions” post category for those announcements. I’ll be soliciting presenters, and the goal is just to provide you with varied technical content around PowerShell. If you’d like to BE a presenter, hit the Contact link in the Site Info menu (above) and let me know! Attending live will obviously give you a Q&A opportunity as well. Be on the lookout! I’m hoping to kick off in September or October. If there are specific topics you’d like to see, drop a comment below and let me know. I’m sure potential presenters would love some suggestions, and I know I would.
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? (BTW, this is TOTALLY a chance to “sell” your suggestion - so do so! The criteria below are what’s really important to us, so help us understand how a given city helps meet all of that criteria! And, if you’re willing to help be our local ‘person on the scene’ to help organize, mention that also!) -– City Selection Criteria for PowerShell Summits This guide is intended to provide a framework for selecting an appropriate city and venue for a PowerShell Summit. Understand that a PowerShell Summit is meant to be a continent-level event, meaning the attendance of international speakers and attendees is a given. A PowerShell Summit is conducted primarily, if not entirely, in English, that being the “de facto” language of the technology industry, and the most-common language spoken by expert presenters in the field. A PowerShell Summit is open to everyone, and is not intended to fill the need for regional, culture- or language-specific events of any size. PowerShell.org recognizes the need for, and value of, those more-regional events, but the PowerShell Summit does not seek to full that need or provide that exact same value. Throughout this guide, note that “venue” does not refer to a city. While in casual discussions we may refer to a city name or metropolitan area name - like London or Munich - our venue may not in fact be within the legal limits of such a city or area. “Venue” refers to a specific facility, which may be a hotel or a conference center or other specific location. Our expectation is that most attendees will arrive at the event via common carrier - typically, train or airplane. Some may drive, but our focus is on providing good access for those who do not have their own personal transportation during the event. Criterion 1: Airport Access The first criterion is easy access to a major international airport. This is intended to accommodate the wide variety of attendees expected. In general, the venue should be either within a 15-20 minute drive from an airport by private car (including taxis and shuttle busses), or within a 30-minute ride via mass transit rail (specifically excluding public bus service, but including all levels of rail access). Exception: The airport service area may be widened in instances where a venue offers significant other advantages in other criteria, or where the venue offers specialized access to expert presenters - e.g., using Bellevue for its convenient access to the PowerShell team, despite the fact that it is a ~30 minute ride by private car from SEA-TAC airport and lacks public rail access to the airport. Criterion 2: Local Transit The venue must be well-connected to the local area by mass transit rail (tram, train, metro, etc.). Alternately, the area must offer a variety of amenities within walking distance. Our goal is to minimize the need for rental cars to travel to the event venue from local hotels, restaurants, and other amenities. A 15-minute walking radius is a good “maximum” guideline. Due to this criterion, local parking fees are explicitly not considered during venue selection, although the organization recognizes than some local attendees may be impacted by parking fees. Criterion 3: Evening Amenities The selected venue must be accessible (via local rail transit or short walks) to evening amenities, including hotels, restaurants, and so forth. While the PowerShell Summit will often include evening events, attendees must have independent access to these kinds of amenities. Criterion 4: Price, Quantity, and Quality of Lodging The selected venue must be accessible (via local rail transit or short walks) to hotels of at least 3-star quality (as listed on travel Web sites such as Expedia or Orbitz), with as reasonable a price as possible given the choices of venues under consideration. When possible, the organization will reserve a room block for at least 1/3 of the expected attendance number (with the understanding that room blocks carry significant financial risk, and the organization has a primary goal of mitigating such risk). Additional hotel capacity meeting this criterion must be available, but may not necessarily be reserved, for the event. Criterion 5: Language The selected venue must be in an area where English is commonly spoken, at least by hospitality workers. English need not be the dominant language in the area, but as it is the “common language” of PowerShell, English must at least be commonly understood as a “lingua franca” in order for a maximum number of attendees to be able to navigate the area. Venues that do not meet this criterion may still be viable locations for a regional, cultural-specific event, but might not be qualified for a PowerShell Summit. Criterion 6: Centrality Given all of the other criteria previously listed, it is desirable to have a venue that provides equitable travel access from the majority of the target area. However, the organization recognizes that central location is often the most difficult to achieve in combination with the other criteria listed. Criterion 7: Accessibility The venue must conform with a general international standard of access for disabled persons, and must provide at least basic ability to meet common dietary restrictions, such as vegetarianism. The organization accepts that extremely specific dietary needs, such as cultural or religious needs or allergy concerns, might incur extra costs that would be passed along to the concerned attendee(s). Criterion 8: Appropriateness The venue must provide appropriate meeting facilities. This means the venue must be able to accommodate the expected number of attendees in a comfortable and safe surrounding, and attendees must be able to access the venue without undue overhead (e.g., extensive security checks in an office building, etc.). In multi-track events, meeting rooms should be able to accommodate a 15-20% offset (e.g., in a 300-person event with 300 attendees, each room must be able to handle 120 attendees, to deal with the fact that some sessions will be more popular than others).
$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. The first uses a more “pipeline” style approach, and I’ve personally never felt the urge to do that in a script. Probably habit - I come from the VBScript world, so a construct like foreach($x in $y) is natural for me. I’ve seen folks get into that “pipeline” approach inside a script and get into trouble, and if I’m scripting I often prefer to use the more formal, structured approach of the version 2 snippet. What’re your thoughts? For me, version 1 has some downsides - forcing yourself into that pipeline structure can be limiting, and I find the approach in version 2 to be more readable and a bit easier to follow. Frankly, I’m never a fan of having to mentally track what’s in $. (Which brings up a sidebar: I tend to evaluate a script’s goodness based on how well I can understand what it does without running it. That’s a common criteria, in fact, and one I personally think helps aid in debugging as well as maintaining scripts.) _ Anyway… discuss! [boilerplate greatdebate]
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. Please forward this to your colleagues and co-workers, as well - we would really like a variety of opinions. If you want to tweet about it, Facebook it, or anything else to help us get a broad perspective, it would be much appreciated. I must note that this event will be in English, as it is meant to be a pan-European event that involves as many different folks as possible. We are not attempting to hold a more regional, culture-specific event - some of those already exist (I’m aware of one in Germany, for example), and they do a better job serving their local market (which can be quite large) than we could ever do. We are trying to fill a different need, which is more along the lines of a very miniature TechEd Europe, which brings as many different folks together as possible. Hopefully we will achieve that goal. Thank you for your time and input!
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. My personal beefs with this:
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? You’d need to leave some obvious details, like the approximate size of your organization (number of users), what you expected the software to do, what it really did, what you liked, what you didn’t like, and so on. Such a site would be a lot better (I think) than magazine or “professional” reviews, since you’d be reading the experiences of people who actually use the stuff every day. Yeah, as with any publicly-contributed content, review quality will vary - but you already know how to read between the lines, right? 😉 Drop a comment, or even send a tweet to @concentrateddon with “Reviews: YES!” or “Reviews: NO!” comment. Or if you prefer Facebook, leave that comment on my FB page. It sure seems like we IT professionals could use something like this - it’d be a good place to start researching solutions to particular problems, and a good place to share some real-world intel on how different solutions really work. Even if you don’t like writing reviews, would you use such a site as part of your research process?
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. This is a huge deal. It means their cloud services (think Azure, O365, and the like) get stuff first, where Microsoft can make sure it’s stable. They then package those and hand them off to us. It means we get better stability, but it also means we get better manageability. Look, you don’t get excited when you have to deploy a new server, right? You want to automate that stuff. Well, Azure gets really ticked off if they can’t automate it, because they do it thousands times more than you. So forcing themselves to run a ginormous datacenter also forces the company to make better management tools - which they then hand down to us in an OS release. If, that is, you’re managing your datacenter as if it was your own little… dare I say it, private cloud. In other words, if you think of your datacenter as a wee little cloud, and you manage it like one, then you’ll get the tech you need, because Microsoft has to develop that tech for themselves. If you want to keep managing it the old-fashioned way… well, you’ll get less love. This whole approach, for me, is the ultimate expression of the Microsoft phrase, “eat the dogfood.” Meaning, use our own products just as our customers would. You just have to make sure you’re eating the same flavor dogfood. Not that MS expects everyone to have their own in-house Azure. No, that’s not the point. The point is that they’re developing for a world where admins do nothing but create units of automation, and business processes (perhaps outside IT) initiate those processes. You’re going to see more and more tools and technologies (um, PowerShell) to facilitate that model of IT operations; you’ll see less and less tech that facilitates the old way (meaning, fewer and less robust GUI tools, I’m guessing). Desired State Configuration (DSC) is probably an ideal example of this new approach. In the past, when you wanted to configure a few hundred machines to look and behave a certain way, you went clicky-click a few hundred times in a GUI. That’s imperative configuration; you tell each machine what to do. That doesn’t scale to cloud-sized proportions, and so now we’re getting DSC. DSC is declarative configuration, meaning you tell a group of machines what to be. The OS itself figures out how to achieve that state of being. So admins have to shift from thinking “what do I make the machine do” and “how do I tell it what to be.” It’s not unlike Group Policy, actually, which is also declarative, except that DSC will eventually dwarf Group Policy in terms of reach and capability. Point being, if you’re in the old world of, “I just run through the Wizard and set the machine up,” you’re not aligned with the new world order. Expect fewer wizards, as product teams shift their investment to building things like DSC resources instead. With 12-18 month product cycles, time is in short supply for each new release. One-at-a-time approaches don’t scale to the cloud, so those are likely to get less of that limited amount of time. Anderson’s post is worth a read. It’s a little high-level - the man is a Corporate VP, after all - but it shows where Microsoft is pointing their collective brain. It uses the word “delight.” It describes in great detail how Microsoft is trying harder to put the customer in the front of every conversation - but, more subtly, it also shows how Microsoft is moving the conversation past “what do customers tell us they want” and more toward “here’s what we see customers needing.” Henry Ford would be proud.
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. It’s a shame this one snuck past them, but once notified of the problem they really did jump on it. The fact that the problem was (from the public perspective) just with the downloadable help files means it’s an easy fix that doesn’t involve pushing code out through Windows Update (thank goodness).
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:
