Blog: Powershell

I couple weeks ago, I was trying to find a way to copy a whole folder of file names all at once. I found a quick way to do it using a PowerShell command.

To do it, hold down Shift and right click on the folder that has the file names you would like to copy. Click Open PowerShell window here from the drop down menu to open up PowerShell. To get the file names, use the command, Get-ChildItem –name . The names of the files will be displayed in PowerShell, and to copy the file names, just highlight the file names and they will be copied to your clipboard:

Recently I wanted to test a dual factor authentication solution on my Windows VM, so I took a snapshot to revert to later if needed. After testing for several days I reverted to the snapshot, but started getting an error about an expired computer account password. Apparently the machine password expired and automatically renewed while testing, so this was lost when I reverted to the old snapshot.

Rather than disconnect and rejoin the computer from the domain, I found a Powershell command to reset the machine password. Details about this command are at:

https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.management/reset-computermachinepassword

I had a customer that opened Outlook and discovered a public folder had mysteriously disappeared. I could not locate the folder anywhere so I assumed it had been deleted.

The good news is there is a PowerShell script that searches and generates a .txt file listing any public folders that were recently deleted. Once you locate the public folder in the text file, you can run another PowerShell command to restore the public folder with its contents.

Here is the link that has both scripts, along with a step by step process of recovering the folder:
 
http://blogs.technet.com/b/exchange/archive/2013/08/23/recovering-public-folder-information-in-exchange-2013.aspx
 

I was recently working on a PowerShell Script that used Excel COM objects to pull data from remote computers put it into a spreadsheet. I finished up the script and tested it under my own account and got the result I was looking for—the data was pulled from the remote computers, an Excel spreadsheet was created and saved to a network share, and an email was sent out with the spreadsheet as an attachment.

Pleased with the script, I set it up as a Scheduled Task and set it to run under the credentials of an existing service account. When I manually ran the scheduled task, however, the script would not run. I tried using my own account for the scheduled task and it still would not run. I was using some formatting in Excel that would have been lost if I went with a CSV file and having to remember to manually run the task at the scheduled interval while I was logged in would not have been the best solution, so I decided to look for a solution rather than re-write the code.
 
After some digging, I discovered PowerShell scripts that use Excel COM objects—and presumably other COM objects—that run while a user is not logged in require the SystemProfile have a Desktop folder in order to run as scheduled tasks. The folder, however, does not exist under the C:\Users directory as you might expect. Instead, it is located at:
 
C:\Windows\System32\config\systemprofile\Desktop
                *AND*
C:\Windows\SysWOW64\config\systemprofile\Desktop
 
The empty “Desktop” directory itself needs to be created and nothing more—no special permissions or registry hacks. In the case of a 32-bit OS, only the first directory needs to be created. In the case of a 64-bit OS, *both* directories need to be created. In my case, I was on a 64-bit OS and the directory in System32 existed but the directory in SysWOW64 did not. Once I created the missing directory I was able to use the original service account to successfully run the scheduled task whether or not it was logged in to the system.

If you want to apply Out of Office settings on several email accounts at one time, you can use PowerShell. By running the PowerShell command below it will enable Out of Office and allow setting an internal and external message.

Set-MailboxAutoReplyConfiguration <alias> -AutoReplyState enabled -ExternalAudience all -InternalMessage <Message to internal senders> -ExternalMessage <Message to external senders>

This works great except the message will wrap text; however, this PowerShell command does support HTML, so you can use HTML tags to apply paragraph and line breaks if you want.

This may be old hat for people that work with Exchange on a regular basis. However, for the occasional Exchange tinkers among us, there is a way to run PowerShell functions that are specifically built for Exchange without having to run the Exchange Management Shell. [more]

1. Open PowerShell on your workstation
2. Use the "PSSession" commands to bring up a PowerShell instance that is pointed at the Exchange server:
   • $session = New-PSSession -configurationname Microsoft.Exchange -connectionuri http://<<Exchange server name>>/powershell -credential <<domain name>>\<<Exchange admin account>>
   • Import-PSSession $session
   • NOTE: the account used in the first command must be a member of one of the Exchange administrator groups in AD. Simply having Domain Admin rights is not enough. When the first command is run, a pop-up box will prompt you for the account's password.
3. You can now run Exchange-specific PowerShell functions!

I was recently assigned a task to pull a list of users who use mobile devices for company email. I came across a neat website with several PowerShell commands listed to help generate the list.

http://www.msexchange.org/articles_tutorials/exchange-server-2010/management-administration/mobile-device-management-part2.html

There is a command to generate a device count of each type of device used.  There is also a command to generate six different .CSV files that can be used to see a list of users, emails received, type of device, device id, etc.

I was tasked with upgrading a 2003 Windows Server to 2008 over the weekend recently and ran into a few minor issues trying to get the upgrade started. The main one was that the Server 2008 installer would not continue past the compatibility check as long as Windows PowerShell 1.0 was installed. PowerShell 1.0 was released as a hotfix prior to server 2003 SP2 and was included in the SP2 package. When I went into Add/Remove Programs, I didn’t see the PowerShell update in the list. Even after removing SP2, PowerShell was still present on the server and would not allow the Server 2008 upgrade to even start. [more]

I wanted to try manually uninstalling the hotfix from the $NtUninstallKBXXXXXX$ folders located in C:\Windows, but the folder that housed the PowerShell 1.0 hotfix info was nowhere to be found. Most likely, someone had removed those folders to clean up disk space or they were removed with the installation of SP2. In either case, I was stuck.

Fortunately, we had another Server 2003 32bit machine running out on the network that still had the $NtUninstallKBXXXXXX$ folder that I needed. I copied it over to this original box and tried the uninstaller. It successfully uninstalled PowerShell without any extra registration on my part! After this was removed, the upgrade to Server 2008 ran smoothly.

VMware PowerCLI is a set of Windows PowerShell snapins that provide access to the VMware infrastructure just like the vSphere client.  It has 165 commandlets.  This will connect directly to hosts just like the vSphere client will, so it can be used to manager smaller installations.  While very powerful scripts can be used for doing just about anything, here are some simple examples:

• copying ISOs to and from the datastore
• powering on or off machines
• rebooting machines
• seeing how much space a machine is taking up

There are many scripts already written and available on the net, so search around before going to very much trouble to write your own. [more]

You can download PowerCLI from http://communities.vmware.com/community/vmtn/vsphere/automationtools/powercli.  This page has several links, including a link to a getting started guide.