Powershell Megathread: Verb-Noun Scripting is the future

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Powershell Megathread: Verb-Noun Scripting is the future

«‹›94 »

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

TheEffect posted:

Very simple script here. It works on one machine but not another. On the machine it doesn't work on, a command window comes up for a brief second showing some error that I can't read and then closes. When I run the script via the ISE however it works perfectly so I have no idea how to capture the error. Anyone know what the issue could be?

Here's the script-

$user = Read-Host "Enter the AD Account you wish to target"
$newpwd = Read-Host "Enter the new password" -AsSecureString
Set-ADAccountPassword $user -NewPassword $newpwd �Reset

Guesswork is sloppy debugging. Instead of double-clicking the script, start a persistent powershell.exe or cmd.exe window, then run the script from there so you can see the error it's kicking back.

That said, it's probably the execution policy.

# ? Dec 29, 2014 20:23

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 00:41

The Electronaut: May 10, 2009

Misogynist posted:

Guesswork is sloppy debugging. Instead of double-clicking the script, start a persistent powershell.exe or cmd.exe window, then run the script from there so you can see the error it's kicking back.

That said, it's probably the execution policy.

Is the AD module loaded?

# ? Dec 29, 2014 20:27

TheEffect: Aug 12, 2013

Misogynist posted:

Guesswork is sloppy debugging. Instead of double-clicking the script, start a persistent powershell.exe or cmd.exe window, then run the script from there so you can see the error it's kicking back.

That said, it's probably the execution policy.

The thing is, it works fine in both of those cases as well (hadn't checked a persistent PS window prior to this, only command, but same result).

The Electronaut posted:

Is the AD module loaded?

The PS AD tools or whatever are active in Windows Features, which as far as I'm aware is all that's needed.

# ? Dec 29, 2014 23:23

vanity slug: Jul 20, 2010

Add Import-Module ActiveDirectory as the first line to your script and it'll work. Just because it's installed doesn't mean it's active.

# ? Dec 29, 2014 23:34

TheEffect: Aug 12, 2013

Jeoh posted:

Add Import-Module ActiveDirectory as the first line to your script and it'll work. Just because it's installed doesn't mean it's active.

Why doesn't this need to be done in my other environment though?

Same behavior after adding that in.

Edit- Just found out what the issue was. It doesn't like being double-clicked from a shortcut location for some reason apparently...

TheEffect fucked around with this message at 23:56 on Dec 29, 2014

# ? Dec 29, 2014 23:53

The Electronaut: May 10, 2009

It depends on the configuration, I guess. When writing scripts, I always do pre checking at the top for the modules, settings, etc. that I need to do to ensure the script will run in the context I need. I wrap up a if(!(get-module activedirectory)){import-module activedirectory} for instance so that I load it only if it is needed. Same with Exchange, clustering, or whatever.

Thanks for providing the problem's solution.

# ? Dec 30, 2014 14:45

Briantist: Dec 5, 2003; The Professor does not approve of your post.; Lipstick Apathy

The Electronaut posted:

It depends on the configuration, I guess. When writing scripts, I always do pre checking at the top for the modules, settings, etc. that I need to do to ensure the script will run in the context I need. I wrap up a if(!(get-module activedirectory)){import-module activedirectory} for instance so that I load it only if it is needed. Same with Exchange, clustering, or whatever.

Thanks for providing the problem's solution.

You don't need to check if the module is loaded; there's no harm in calling Import-Module again. Also in Powershell 3+, modules are loaded automatically when they're in the designated paths, so for the most part Get-Module will return true anyway. I still use Import-Module with -ErrorAction Stop so that if a particular module can't be loaded, an exception will be thrown.

code:

Import-Module ActiveDirectory -ErrorAction Stop

If you're using Powershell 3+ you can also use a #requires statement at the top which tells Powershell that these modules must be available:

code:

#Requires -Modules ActiveDirectory,DhcpServer

about_Requires

# ? Dec 30, 2014 18:29

The Electronaut: May 10, 2009

Briantist posted:

You don't need to check if the module is loaded; there's no harm in calling Import-Module again. Also in Powershell 3+, modules are loaded automatically when they're in the designated paths, so for the most part Get-Module will return true anyway. I still use Import-Module with -ErrorAction Stop so that if a particular module can't be loaded, an exception will be thrown.
code:
Import-Module ActiveDirectory -ErrorAction Stop
If you're using Powershell 3+ you can also use a #requires statement at the top which tells Powershell that these modules must be available:
code:
#Requires -Modules ActiveDirectory,DhcpServer
about_Requires

You're right. I started doing it as I was dealing with Exchange 2010's pssession behavior, which does bomb out at 16 instances or the like.

Thank you for the heads up about the requires behavior, neat stuff.

# ? Dec 30, 2014 21:19

TheEffect: Aug 12, 2013

Thanks for the additional info guys, very insightful.

Any idea why when trying to run it from a shortcut location it would case this behavior? Something obvious I'm missing probably.

# ? Jan 5, 2015 15:29

Dr. Arbitrary: Mar 15, 2006; Bleak Gremlin

I think it has to do with the "Start In" parameter.

# ? Jan 5, 2015 15:57

TheEffect: Aug 12, 2013

Dr. Arbitrary posted:

I think it has to do with the "Start In" parameter.

Hmm, I changed that but I still had the issue.

I managed to sniper-snapshot the error and apparently it was trying to use the directory location as a function? The error reads-

quote:

"(directory I'm using): The term '(directory I'm using)' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify the path and try again".

I noticed that the directory it was giving was cut-off at a space character. I changed the name of the folder by replacing the spaces with underscore and it works perfectly. Still not sure why though.

TheEffect fucked around with this message at 17:38 on Jan 5, 2015

# ? Jan 5, 2015 17:33

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

I'm trying to write a quick Powershell batch script that calls a couple of other Powershell scripts that I've written. These other scripts output Japanese characters out to the console, and while console output looks fine when I run the script files by themselves, when I run them via my batch script all of the Japanese characters are replaced by question marks. How can I preserve UTF-8 output when I'm calling my scripts?

Here's what I have so far:

code:

param(
    [string] $siteUrl,
    [array] $ssYears
)

# Export ListMasters
powershell $PSScriptRoot\listmasters_export.ps1 $siteUrl

# Export Reports
powershell $PSScriptRoot\listreports_export.ps1 $siteUrl $ssYears

# ? Jan 5, 2015 19:34

Mindisgone: May 18, 2011; Yeah, well you know...
That's just like, your opinion man.

Does anyone have any experience with the MSOL plugin for office 365?

Specifically I created a powershell script to create a user based on first and last name. It creates the user in AD, assigns them to the correct security groups, creates their email in office 365. My issue is then having the script add that email to the correct distro groups.

I had done some testing with this a few months back and the issue was in the MSOL session. The script will create the email but it never rereads or refreshes the user list from 365 before proceeding with adding it to the group because the error is always 'this email object does not exist'. What I did a few months back was create a separate script to add the email to the distro groups so the creation script would finish and the last line of the creation script invoked the grouping script.

Now today I hosed with the script and cannot get it to work right again. The creation script still invokes the grouping script but I am getting the 'object does not exist' anyway :doh:

EDIT: Also does anyone know how to read credentials into the MSOL plugin from a file or something so it does not need to be typed every time? All of the Google-Fu results do not work on the MSOL plugin.

Mindisgone fucked around with this message at 21:17 on Jan 5, 2015

# ? Jan 5, 2015 21:15

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Karthe posted:

I'm trying to write a quick Powershell batch script that calls a couple of other Powershell scripts that I've written. These other scripts output Japanese characters out to the console, and while console output looks fine when I run the script files by themselves, when I run them via my batch script all of the Japanese characters are replaced by question marks. How can I preserve UTF-8 output when I'm calling my scripts?

Here's what I have so far:

That's a weird one, this might help:
http://stackoverflow.com/questions/22349139/utf-8-output-from-powershell

According to one of those guys, it's actually a bug that it doesn't work in UTF16 by default.

# ? Jan 5, 2015 21:42

Mindisgone: May 18, 2011; Yeah, well you know...
That's just like, your opinion man.

Mindisgone posted:

Does anyone have any experience with the MSOL plugin for office 365?

Specifically I created a powershell script to create a user based on first and last name. It creates the user in AD, assigns them to the correct security groups, creates their email in office 365. My issue is then having the script add that email to the correct distro groups.

I had done some testing with this a few months back and the issue was in the MSOL session. The script will create the email but it never rereads or refreshes the user list from 365 before proceeding with adding it to the group because the error is always 'this email object does not exist'. What I did a few months back was create a separate script to add the email to the distro groups so the creation script would finish and the last line of the creation script invoked the grouping script.

Now today I hosed with the script and cannot get it to work right again. The creation script still invokes the grouping script but I am getting the 'object does not exist' anyway

EDIT: Also does anyone know how to read credentials into the MSOL plugin from a file or something so it does not need to be typed every time? All of the Google-Fu results do not work on the MSOL plugin.

First time I ever quoted myself :colbert:

...

Solution #2, storing MSOL credentials:

Get-Credential "admin@ScriptingGuy.OnMicrosoft.Com" | Export-Clixml c:\fso\ScriptingGuyCredential.xml
run this in a fresh PS window to create your credential XML

$Cred = Import-Clixml C:\fso\ScriptingGuyCredential.xml
use this line in scripts before the Connect-MsolService -Credential $cred command

credit to scriptingguy.com

# ? Jan 5, 2015 22:12

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Another solution: source control your poo poo

# ? Jan 6, 2015 02:40

Briantist: Dec 5, 2003; The Professor does not approve of your post.; Lipstick Apathy

Mindisgone posted:

First time I ever quoted myself ...

Solution #2, storing MSOL credentials:

Get-Credential "admin@ScriptingGuy.OnMicrosoft.Com" | Export-Clixml c:\fso\ScriptingGuyCredential.xml
run this in a fresh PS window to create your credential XML

$Cred = Import-Clixml C:\fso\ScriptingGuyCredential.xml
use this line in scripts before the Connect-MsolService -Credential $cred command

credit to scriptingguy.com

Keep in mind that the credential will be stored encrypted, but it can only be decrypted by the user you used to encrypt it, on the machine on which you encrypted it. A different user and/or machine will not be able to successfully import it (this can bite you in the case of a scheduled task, for example).

What I've done in the past is to run the first snippet with several users with a filename like username_credential.xml or something similar. Then when you import:

code:

$cred = Import-Clixml "C:\fso\${env:USERNAME}_credential.xml"

Then you can add new users without altering your code.

If you need it to work on different computers too, you can incorporate the computer name into the filename the same way, and use the COMPUTERNAME environment variable in the code.

I've mostly used these so that I can develop with my own user even though I will be running a scheduled task as a service account; this way I don't have to keep changing the code or changing the credential file.

# ? Jan 7, 2015 22:20

Mario: Oct 29, 2006; It's-a-me!

TheEffect posted:

I noticed that the directory it was giving was cut-off at a space character. I changed the name of the folder by replacing the spaces with underscore and it works perfectly. Still not sure why though.

You probably had something like this as your shortcut:

code:

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe C:\Users\User1\New Folder\script.ps1

Instead of quoting the full path:

code:

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe "C:\Users\User1\New Folder\script.ps1"

# ? Jan 9, 2015 07:45

TheEffect: Aug 12, 2013

Mario posted:

You probably had something like this as your shortcut:
code:
%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe C:\Users\User1\New Folder\script.ps1
Instead of quoting the full path:
code:
%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe "C:\Users\User1\New Folder\script.ps1"

You're right! I put the path in quotes and it works perfectly now. Thanks for the explanation!

# ? Jan 9, 2015 17:59

Swink: Apr 18, 2006; Left Side <--- Many Whelps

I'm replacing vbs login scripts with powershell versions. Whats the proper way to handle execution policy on workstations? Is it a bad idea to set them all as unrestricted?

Should I sign each of my scripts? And do they need to be resigned each time they're modified?

Swink fucked around with this message at 02:04 on Jan 12, 2015

# ? Jan 12, 2015 02:02

Briantist: Dec 5, 2003; The Professor does not approve of your post.; Lipstick Apathy

Swink posted:

I'm replacing vbs login scripts with powershell versions. Whats the proper way to handle execution policy on workstations? Is it a bad idea to set them all as unrestricted?

Should I sign each of my scripts? And do they need to be resigned each time they're modified?

If you are using the logon scripts GPO, and storing the scripts with the GPO (use the Show Files button), then you don't need to worry about the execution policy.

# ? Jan 12, 2015 04:21

Swink: Apr 18, 2006; Left Side <--- Many Whelps

Some will, but some will just be called by the user via double clicking a batch script, or in the startup directory.

# ? Jan 12, 2015 04:38

Briantist: Dec 5, 2003; The Professor does not approve of your post.; Lipstick Apathy

Swink posted:

Some will, but some will just be called by the user via double clicking a batch script, or in the startup directory.

In this case, execution policy does matter.

If you're calling it from a batch file, then you can invoke powershell this way:

code:

powershell.exe -ExecutionPolicy Bypass -File "C:\whatever\script.ps1"

You can use whichever execution policy you want here (RemoteSigned, Unrestricted, Bypass); it's only for that invocation.

I typically recommend some additional switches, depending on what you're doing:

-NoLogo -- Just like in VBScript, don't display a logo
-NonInteractive -- For scheduled tasks and things that don't have a user to answer prompts
-NoProfile -- Doesn't load profile scripts; makes script behavior more predictable across different users.

# ? Jan 12, 2015 18:06

Swink: Apr 18, 2006; Left Side <--- Many Whelps

Perfect. You are a golden goose!

# ? Jan 13, 2015 08:46

Wicaeed: Feb 8, 2005

Has anyone used Powershell & racadm to gather system inventory from a local system?

# ? Jan 16, 2015 02:38

Dr. Arbitrary: Mar 15, 2006; Bleak Gremlin

Wicaeed posted:

Has anyone used Powershell & racadm to gather system inventory from a local system?

I've done some inventory work with Powershell. I'll post my scripts tomorrow if you want to collaborate and make something neat.

Edit:
I don't know what racadm is, so maybe we're talking about totally different things.

# ? Jan 16, 2015 04:18

myron cope: Apr 21, 2009

Dr. Arbitrary posted:

I've done some inventory work with Powershell. I'll post my scripts tomorrow if you want to collaborate and make something neat.

Edit:
I don't know what racadm is, so maybe we're talking about totally different things.

I would be interested in them, for science

# ? Jan 16, 2015 16:32

12 rats tied together: Sep 7, 2006

Wicaeed posted:

Has anyone used Powershell & racadm to gather system inventory from a local system?

I used a PS script w/ racadm to update our DRAC documentation a while back, since it was incredibly out of date. But, that's system inventory for remote systems from a local system.

I remember it being fairly straightforward. It's not as "easy" to control a command prompt from powershell like it is in say, Bash or Perl, but it's still workable. I think the biggest problem I had was redirecting the output from racadm commands so I could actually parse it.

# ? Jan 16, 2015 17:16

TheEffect: Aug 12, 2013

I'm trying to get a 2 digit month via this method- "thisMonth = Get-Date -format MM" but the VB compiler is underlining "Get" and telling me that an expression is expected.

According to this I'm doing it the right way- http://technet.microsoft.com/en-us/library/ee692801.aspx

Any idea what could be the issue?

# ? Jan 16, 2015 17:18

Briantist: Dec 5, 2003; The Professor does not approve of your post.; Lipstick Apathy

TheEffect posted:

I'm trying to get a 2 digit month via this method- "thisMonth = Get-Date -format MM" but the VB compiler is underlining "Get" and telling me that an expression is expected.

According to this I'm doing it the right way- http://technet.microsoft.com/en-us/library/ee692801.aspx

Any idea what could be the issue?

You're using Powershell in VB? I haven't used VB since VB6 so I don't know how that works.. but in powershell that would work (if you used $thisMonth).

# ? Jan 16, 2015 17:56

TheEffect: Aug 12, 2013

Briantist posted:

You're using Powershell in VB? I haven't used VB since VB6 so I don't know how that works.. but in powershell that would work (if you used $thisMonth).

I'm an idiot. I'm coding for VB, not Powershell. Godamnit. Ignore this post, sorry.

# ? Jan 16, 2015 17:57

Swink: Apr 18, 2006; Left Side <--- Many Whelps

What is the go with powershell's ability to manage network gear? Could I use it to enable/disable switch ports to a schedule, or is that not how it works?

# ? Jan 18, 2015 00:06

Briantist: Dec 5, 2003; The Professor does not approve of your post.; Lipstick Apathy

Swink posted:

What is the go with powershell's ability to manage network gear? Could I use it to enable/disable switch ports to a schedule, or is that not how it works?

Powershell v5 (currently in preview) will have network switch cmdlets, but they're likely only to work on Windows Logo Certified hardware.

NetCmdlets appears to be aimed at managing a wider variety of network switches through SNMP, though I've never used these before so I can't really comment on them.

# ? Jan 20, 2015 22:04

myron cope: Apr 21, 2009

Is it possible to schedule a powershell task that runs without launching a window? I just want it to do its thing, no window needed

# ? Jan 21, 2015 04:48

Dr. Arbitrary: Mar 15, 2006; Bleak Gremlin

Briantist posted:

Powershell v5 (currently in preview) will have network switch cmdlets, but they're likely only to work on Windows Logo Certified hardware.

NetCmdlets appears to be aimed at managing a wider variety of network switches through SNMP, though I've never used these before so I can't really comment on them.

Speaking of Powershell 5, anyone have any luck getting one-get to work?

# ? Jan 21, 2015 07:46

MF_James: May 8, 2008; I CANNOT HANDLE BEING CALLED OUT ON MY DUMBASS OPINIONS ABOUT ANTI-VIRUS AND SECURITY. I REALLY LIKE TO THINK THAT I KNOW THINGS HERE

INSTEAD I AM GOING TO WHINE ABOUT IT IN OTHER THREADS SO MY OPINION CAN FEEL VALIDATED IN AN ECHO CHAMBER I LIKE

Nevermind, I'm going to research more and if I can't figure it out I'll have my thoughts collected so I can do a better write-up.

MF_James fucked around with this message at 22:47 on Jan 21, 2015

# ? Jan 21, 2015 22:27

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

myron cope posted:

Is it possible to schedule a powershell task that runs without launching a window? I just want it to do its thing, no window needed

What OS? I have a bunch of Scheduled Tasks on Windows Server 2003 (oh god don't remind about EOL) that just run in the background. With these settings:
Account: (some specific service account)
Run whether user is logged on or not
Run with highest privileges
Action: Start a program
PowerShell
.\MyScript.ps1
c:\jobs\

# ? Jan 22, 2015 01:00

myron cope: Apr 21, 2009

Scaramouche posted:

What OS? I have a bunch of Scheduled Tasks on Windows Server 2003 (oh god don't remind about EOL) that just run in the background. With these settings:
Account: (some specific service account)
Run whether user is logged on or not
Run with highest privileges
Action: Start a program
PowerShell
.\MyScript.ps1
c:\jobs\

It's a Windows 8.1 machine. It's not a huge deal, but I don't need to see the output so if it's possible to hide I would.

We do have another pc that would be better anyway, maybe I should just move it to that one.

# ? Jan 22, 2015 01:47

ConfusedUs: Feb 24, 2004; Bees?
You want fucking bees?
Here you go!
ROLL INITIATIVE!!

You want

-windowstyle hidden

# ? Jan 22, 2015 03:00

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 00:41

Briantist: Dec 5, 2003; The Professor does not approve of your post.; Lipstick Apathy

myron cope posted:

It's a Windows 8.1 machine. It's not a huge deal, but I don't need to see the output so if it's possible to hide I would.

We do have another pc that would be better anyway, maybe I should just move it to that one.

You can use a -WindowStyle but you might not need it. If you set the task to run "whether the user is logged in or not" then I think it will be hidden (especially on a post XP machine). Either way it's good to be explicit and use -WindowStyle Hidden if that's what you want (as ConfusedUs suggested).

# ? Jan 22, 2015 04:07

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Powershell Megathread: Verb-Noun Scripting is the future

«‹›94 »