Shane's Adventures in Information Technology

Here’s a nifty little trick if you ever need to rename a large set of files (I’m looking at you, thousands of images from my DSLR!):

Dir | Rename-Item –NewName { $_.name –replace “ “,”_” }

This will pipe all the files in your current directory into Rename-Item, and replace whatever is in the first set of quotes (just a blank space here) to what’s in the second pair (an underscore in this example).

Icolan added a good tip on my last post:

 Icolan Says: 
Why not call mmc.exe with the start-process command, then you won’t have a cmd window left open.

Start-Process “C:\Windows\System32\mmc.exe” -workingdirectory $PSHOME -Credential -ArgumentList “dsa.msc”

Why not indeed? 🙂

Simply adding that to the original script though, gave me the error:

“The requested operation requires elevation”

After some research, I found out that the script was starting PowerShell as my administrator account, but that account was not elevated (the elevation does not pass through from my normal logged-in account). The info and solution I found here.

The solution is fairly simple: create a second script to get the administrator credentials, and then call the original script using -Verb runas instead of -Credential.

My desktop shortcut now looks like this:

%SystemRoot%\system32\WindowsPowerShell\v1.0\

powershell.exe&’C:\PowerShell_scripts\DSACopyCall.ps1′

Which is running DSACopyCall.ps1:

Start-Process powershell -Credential <domain\administrator account> -ArgumentList “C:\PowerShell_scripts\DSACopy.ps1”

Which in turn is running DSACopy.ps1 as the elevated administrator:

Start-Process -file $env:windir\System32\mmc.exe -workingdirectory $PSHOME -ArgumentList $env:windir\system32\dsa.msc -verb runas

Works like a charm! Thank you to the technet posters linked above, and extra special thanks to Icolan!

So the old methodology we used to use for opening up Active Directory was a little cmd file:

runas /user:AD\<admin account> cmd

Which would start a new cmd window running under the <admin account> credentials. From there, you could type dsa.msc to start Active Directory running as that <admin account> instead of the account you were logged in as. This worked well enough, but there were a few caveats: first, there were two cmd windows open after you had AD up and running, and second, you had to remember the “dsa.msc” part. Not so hard for an administrator, but perhaps tricky for my student workers.

At lunch today I thought “PowerShell has to be able to do this better” and with some google-fu and trail and error, it turns out I was right. There are three major steps:

1. Run PowerShell as an administrator, then run “Set-ExecutionPolicy remotesigned”. Click “Yes” to the prompt.

2. Create a PowerShell script folder somewhere. I use ‘C:\PowerShell scripts’ but I also tested running this from my desktop, so I believe it could be anywhere (possibly even on a file share, although I would assume you would need to use the FQDN. I should test that). Make a ps1 file (mine is DSA.ps1) with the following (filling in your domain\admin account):

Start-Process “C:\Windows\System32\cmd.exe” -workingdirectory $PSHOME -Credential <domain\admin account> -ArgumentList “/c dsa.msc”

3. Create a shortcut with the following (making any changes if you haven’t used the same folder structure I have):

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe &’C:\PowerShell scripts\DSA.ps1′

Viola! The shortcut will now open a cmd window which will automatically open AD under your admin credentials. No more need to remember dsa.msc, and only one cmd window left open (which can be closed by hand without affecting AD, or you can leave it alone and it will close automatically when you close AD). Not game-changing, but a fun little way to spend my lunch and I learned a few things along the way. Let’s dig a little deeper into what we did:

First, we had to make sure that we could run PowerShell scripts like an executable. This is set to Restricted by default (check your policy with the Get-ExecutionPolicy command). We changed it to remotesigned, which is defined as “Downloaded scripts must be signed by a trusted publisher before they can be run”. For more details, check TechNet: http://technet.microsoft.com/en-us/library/ee176961.aspx

Second, we created the actual script itself. It calls the Start-Process cmdlet, specifying the filepath (which is a positional parameter, so we don’t need to explicitly name it, although we could), as well as the working directory, credential, and an argument list to pass to cmd. The /c part tells cmd to run the command listed (which ours is dsa.msc). The /c argument is supposed to tell cmd to run the command and terminate, but it won’t terminate until the command is complete. In other words, this is why the cmd window stays open until we close AD which completes the command.

Last, we create a handy little shortcut for ourselves, calling PowerShell with the script we wish to run. You can also do everything detailed here with printmanagement.msc for the Print Management console. Happy hacking!

Found a nice little powershell command to get info on printers installed on a print server:

Get-WmiObject -class Win32_printer -computer <print server name/IP address> -credential <domain\username> | Select Name,Comment,DriverName,location,PortName | Export-Csv c:\PrintServerInfo.csv

Want to know who is currently logged into a machine?
(gwmi Win32_ComputerSystem -Comp).username

PowerShell <3

This is my first post at my SA:IT blog! I just got back from Orlando, FL where I attended Microsoft TechEd 2012. While it was a great experience and I learned a lot, it was also really exhausting!

There was so much to do and see I was honestly very overwhelmed. I arrived late Saturday afternoon and crashed in my hotel room basically on arrival. I stayed at the Rosen Centre, right across the street from the Orange County Convention Center, which actually was really nice (both the hotel and the location). I never had to wait for a hotel shuttle, I could just walk on over.

The following day, Sunday, was my pre-conference seminar: Real World Windows Deployment Using the  Microsoft Deployment Toolkit 2012 hosted by Michael Niehaus and Mikael Nystrom. Both of the speakers were great, and I learned a lot despite the wicked jet-lag. It really sunk in for me that the Light Touch Deployment we have been hammering out in our office is definitely where we need to be. Once we’ve got System Center Configuration up and running we can reconsider a Zero-touch deployment. There is much more to say on this topic, but I think MDT will be deserving of it’s own post in the future.

Monday through Thursday were a blur of breakfasts, information sessions, lunches, vendors, and my favorite of all: the hands-on labs. I’m all for visual and auditory learning, but for me, the best way to learn is to dig in and get my hands dirty.

The hands-on labs area was huge. Hundreds of computers, broken into four basic sections so that you could sit in your area of interest and ask questions of the Microsoft staff who specialize in that interest. Each workstation had a list of labs to choose from, broken down by general category. Once you selected a lab, a Virtual Machine would boot up, with a step-by-step PDF to walk you through the process. I was pleasantly surprised to see that our own documentation in our office is at least on par with Microsoft’s (better, I would say, in some ways. Microsoft’s was verbose to the point of distraction at times, and other times repeated unnecessary information).

There was also a certification testing and learning center nearby. I got to take a practice exam for the 70-680 certification I am working on this summer. What was really great about the practice test was that as you answered questions, you could see if you got them right or wrong as you went. It would not only tell you what the right answer was, but had an explanation on why it was the right answer. Once you were finished it also broke down how well you did in a number of categories, allowing me to focus on my weak points. Really great stuff. I picked up the MCTS Self-Paced Training Kit (Exam 70-680): Configuring Windows® 7 book from the Microsoft store. Expect some blog posts on this topic as well.

The vendors area was fun as well, with all the stress-balls and t-shirts they were giving away. I was able to meet up with a few of the vendors we already use: Secunia, ProofPoint, etc. I wasn’t really there for the swag, so I didn’t spend too much time there. The best swag I got, imho, were the free books.

There was also a game center area to unwind at, which I thought was pretty neat. They had some great classic arcade games (Ms. PacMan, Mario Bros., etc) all free-to-play. There was also billiards and skee-ball as well.

Overall, there was a lot of talk of the cloud, Windows 8, and Windows Server 2012. While we are moving towards a private cloud (of sorts) here in our office, I still wonder how much the public cloud will be adopted IRL. I understand a little more about it to see that it’s more than just a marketing buzzword, but I think I still need to wrap my head around the three basics of what makes a cloud a cloud (according to my “Introducing Windows Server 2012” book, those three are: Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). This too, I think will need it’s own post). Windows Server 2012 looks neat though, I’ve got the Release Preview installed on a lab machine although I haven’t done much with it yet.

Windows 8, however, is a different story. I got a chance to play with it on a tablet, laptop and touch-enabled desktop and I have to say, I came away not impressed. I don’t see a big return on investment for our office here. I’m not a big fan of the Metro UI, even when touch is involved. Unless there are some radical changes before release or I become aware of some killer feature, I think we will skip it as much as possible. The newly announced Windows Surface may be the only place I’m willing to concede. I wouldn’t be surprised if a number of IT shops leap-frogged over 8 in the same way we leap-frogged over Vista.