Tag: powershell

This is part of my Powershell Challenge, to learn more about PowerShell (PoSh) using the Learn Windows Powershell 3 in a Month of Lunches book by Don Jones.

This chapter is a practical one. Build a scheduled task that removes all jobs from a certain printer. Not that hard, but we’re using Powershell, and I’ve never done this for sure.

The chapter walks you through a process, though I’m not sure this is the best one. After all, building scheduled tasks from Powershell seems to be overkill, especially since I’ve rarely scheduled the same thing across multiple machines. Except SQL Agent, and there it’s certainly easy to use T-SQL to do so. However, I get the idea. They want you to work through looking for commands, and then figuring things out within Powershell.

The other problem I have from this item is that there are typos. The command they first show with a parameter of “printer”, but that caused me errors. It needs to be “printername”. That threw me at first, and made me think if things didn’t work, I wouldn’t know where the errors were.

As I worked along with the authors to create a task, trigger, action, etc. I felt somewhat empowered, but I also felt that they didn’t quite explain the details enough of how they delve into the commands. A lot of information is returned when you run help, and it can be confusing or difficult to choose which items to link and how. Overall, I felt they shortcut’ed the explanation a bit for people learning Powershell.

However, the lab was similar. Create a folder and share it.

I’ve done this lots of times, but not with PoSh. I knew that many of the DOS commands like “mkdir” work, but I wanted to find out what was the basis. A little help showed me this was the New-Item command. A few experiments and I had created a C:\Labs folder on my machine. I was thinking this would be a pipeline command, so I saved it.

$cf = New-Item -path "c:\labs" -type "directory"

When I saw the folder in Explorer, I felt a bit proud of myself.

From there I dug into help with *share* and found the SMB share items. I’ve know that file sharing was with SMB, but I could certainly see some DBAs and others wondering. When I’ve used “SMB” in a few talks, I’ve gotten some blank stares at times. Anyway, I completed the task easily, and figured out I couldn’t pipeline these tasks. However, I had remembered somewhere in my mind that ($cf) would execute that variable, and that worked.

Overall this was a good chapter and exercise. I could certainly see this lab being handy as I’ve often wanted to standardize things, like backup directories, on a lot of servers. I’ve even had standard shares at times.

This was a good building block to learning how to assemble some commands and accomplish a task. I’d like to see 2-3 small tasks like this to help learn how to build to bigger projects. Perhaps that’s coming.

This is part of my Powershell Challenge, to learn more about PowerShell (PoSh) using the Learn Windows Powershell 3 in a Month of Lunches book by Don Jones.

I’ve learned that the dash (-) is going to be my friend. Filtering and comparisons are the backbone of SQL. We use them all the time in our WHERE clauses. In Powershell, we have similar comparisons as I’ve seen, but almost always as I use the eq, ge, le, ne, etc. comparisons, there is the need to include a dash before them. Same thing for -and and -like (see I’m doing it).

This chapter looks at filtering, and how you can reduce the information returned from cmdlets to just those items that you need. The idea of “filtering left”, meaning including the filter as soon as possible in the command. Since commands are interpreted and executed left to right, filtering left means less processing where possible. However since not all cmdlets include a -filter parameter, you must use the WHERE-OBJECT cmdlet.

Overall, the idea of filtering and using comparisons is very much core to what we do in SQL and what happens in many programming algorithms as we look to make decisions in our applications. This chapter helps to understand this.

I also learned about the “$_.” syntax, which is really  a way to specify a generic object and then specify a property for all instances of that object. So if I’m looking at the name for something, I want to use “$_.Name” syntax. I had wondered what that was for in the last chapter, but now this makes sense.

The lab, however, was challenging. I want to use the WHERE syntax when I can do things easier. For example, getting a list of services whose names are “conhost” or “svchost”. I entered:

PS C:\Windows\System32\WindowsPowerShell\v1.0> get-process | where {$_.Name -match "Conhost" -or $_.Name -match "Svchost"}

Way too much overkill. This would do it.

get-process -name conhost,svchost

That’s an area where I need more practice and need to work on things. I suspect much of my initial Powershell work will be more complex, without filtering occurring in the most left point it could unless I manage to understand the details of various commands.

This is part of my Powershell Challenge, to learn more about PowerShell (PoSh) using the Learn Windows Powershell 3 in a Month of Lunches book by Don Jones.

select *

select name, id, status

This is part of my Powershell Challenge, to learn more about PowerShell (PoSh) using the Learn Windows Powershell 3 in a Month of Lunches book by Don Jones.

The authors note this is an optional chapter, one that isn’t necessarily one you need to read. After going through it, I’m not sure I agree, especially as I’m not completely sure I grasp all the contents, though I do think they will be handy.

When you pipe output from one command to another in Unix, it’s really a text stream. Just as it would be written to stdout, it’s sent to the next command. That means your commands need to handle text as inputs.

In PoSh, if I understand this, that’s not the case. The inputs into commands are through parameters for the most part. That means that the output from one command, which is a collection of objects, needs to be accepted in the next. For many commands, that doesn’t quite work.

There are two methods of sending in parameters. One is input ByValue, which is a parameter binding method. In this method, PoSh looks at the type of parameter being sent in, in essence the object type (or data type) and matches to a parameter if the parameter accepts pipeline input. Not all do, and you need to read the HELP for a command to see which parameters accept pipeline input. That seem mis-named to me. It’s ByType, not ByValue in my mind, but I’m certainly not a PoSh expert.

The other way is ByPropertyName, which is as it implies, by name. The object coming in has its name matched with the parameters of the command on the other side of the pipeline.  That makes more sense, though there are times that the names don’t match.

That’s where you can then create custom properties with the Select-Object syntax that creates name/value pairs from your input. It looks like handy, not too complex, but cumbersome syntax. I’ll have to play with this more as I had to work through some exercises and carefully watch my parens and braces (opening and closing) as I typed in some commands.

One thing that frustrated me slightly with these exercises is that a bunch of them looked at multiple machines, and I don’t have a domain at the present time with matching credentials. I couldn’t figure out (easily) how to connect to another machine with custom credentials for Get-Process and Get-Service, but I also was running short of time this lunch, so I skipped.

The lab was analysis without using PoSh, since many people reading the book might not be admins on a domain. I got most of the answers right, but not always the explanation. I certainly think I need to play with this more, and that means I’ll stand up a domain here soon that I can use. I need to do that anyway.

The custom properties, along with the introduction of parens for order of operations, make this a must read chapter for me. I think the authors shouldn’t caveat this one at all.