FYI: Ive been tagging each of my learners daily observations so that you can follow them more easily as a unit, if you like. Use lunches-will for Wills entries - fine the rest in the tag cloud on the right. Also, Ill apologize for the delay between some learners posts. Its not their fault - its mine. Ive been on the road teaching a lot and its been challenging getting enough Internet bandwidth to post - Im gonna try and do better, but didnt want you to think these guys were slacking off!
When I first started working with PowerShell I was pretty happy with the built in functionality, but, fairly quickly started looking for ways to satisfy my hacker nature. I mean, what good is a tool if I cant supe it up, right? Modules and SnapIns are the most straightforward door into this world of extended functionality. It took me a little while to get a grip on exactly what the difference between a Module and a SnapIn is, but, Sections 5.3 (SnapIns) and 5.4 (Modules) give a real good sense for the distinction. There is a lot you can get into when you start exploring these. Before you start looking for the keys to the kingdom, however, it is important to get the distinction between the two down.
Being able to explore (and make sense of) the members of a SnapIn or module is a basic task. As Don said in Section 5.9, be sure and read the help. I spent about two weeks (and a few embarrassing posts on Technet) trying to figure out how to loop through a specific set of arguments to use with the ServerManager module. As it turns out, you just specify a comma-separated list of what you want, and, voila, it is taken care of. Had I taken the 30 minutes to read through the help I would have caught that in the explanation or examples. So, back to my chant, "Read the help! Read the help! Read the help!"
Another really good note I picked up in Section 5.5 was that conflicting command names can be resolved using the fullname to the modulecommand syntax. I have run into problems with this when using the PSCX community extensions module. It has bitten me a few times. Now, I know I can just call the fully qualified name and run with it and not have to worry about name resolution issues. Sweet. One less headache. You can use Get-Command and specify the module name to find out what the ModuleName is to fully qualify a name. Perfect.
It was news to me that the SQL Server team created a minishell for the 2008 version of the product. It was interesting to see how this actually works. Also interesting is the fact that this one time attempt seems to also be the last. So, it helps to know that, in the future, I will not need to go searching for clarification on whether the module (or SnapIn) I want to work with is really a minishell or not. Until I have a reason to think otherwise I will just assume I am working with a module in the normal PowerShell .exe. It is cool to note, however, that, with this SQL Server minishell they actually have a provider so you can explore server contents like drives. Great idea. Hopefully theyll revisit this from another angle.
This got me thinking of a trick I want to try. With MMC you can create customized snapins that can be saved. With PowerShell, desktop icons to launch the shell can explicitly import modules. As Don pointed on one of the DVD tracks, the specific parameters/arguments used to call powershell.exe tell the console what to do. Instead of just loading the "given" shells, I may start picking the few modules I want all the time (task-dependent) and loading modules with the -ImportModule parameter. So, if I am on an domain controller, but, I also do a lot of SQL work from the same machine, I can just click my customized icon and have the ActiveDirectory and SQL Server modules load automatically.
Lastly, something good I learned is that the console file approach (Section 5.8) to preconfiguring files focuses specifically on SnapIns and not Modules. One thing I have heard through the grapevine, yet, not seen as an official statement is which-module or snapin-is the way forward. While there is not authoritative word, the fact that SnapIns seem to be few and far between confirms what I have heard about their being primarily a PowerShell version 1 approach. As we get further into version 3 we may get a hint as to the future of the these two roads. Knowing that SnapIns may be up in the air gets me thinking that profiles (touched on in the same section) really may be the safest way to go for now.
Wednesday, February 3, 2016
0 comments:
Post a Comment