Send an Email from the Windows Command Prompt or Script, Pt II…

2017-07-27T00:01:03+00:00 November 14th, 2013|Uncategorized|

Following up on the earlier post, “Send an Email from the Windows Command Prompt or Script…

…While I’m somewhat picking up where I left off in Part 1, the situation in that earlier post had special requirements about how the email message had to be sent (controlled source, user interaction, etc.).  But what if you don’t have those requirements?  What if you simply want to send an email from a Windows workstation or Server? 

Well, in that case, simply use PowerShell.  Since version 2, PowerShell has included the Send-MailMessage cmdlet for relatively easy mail sending from almost any modern computer.

Recently, I was telling somebody how do use this method to send messages in a script, and demonstrating the input details such as specifying the SMTP relay server.  The person then asked me, “What if the SMTP server changes?”  Hmm…  Good point.   So I whipped up a few extra lines to work around that problem, and the person thought I should post it here.  Agreed!

Here is the script, put together as plainly as possible, with clearly named variables to help you understand what’s going on:

$MyRecipientEmailAddress = ""
$MySenderEmailAddress = ""
$MyRecipient = $MyRecipientEmailAddress.Split("@")
[0] $MyDestinationDomain = $MyRecipientEmailAddress.Split("@")[1] $MyMxRecords = Resolve-DnsName -Type MX -Name $MyDestinationDomain $MyMxRecord = $MyMxRecords[0].NameExchange $MyMessageSubject = "This is a test" $MyMessageBody = "This is the message. Thanks! - Jeremy" Send-MailMessage -To "$MyRecipientEmailAddress" -SmtpServer "$MyMxRecord" -Subject "$MyMessageSubject" -Body "$MyMessageBody" -From "$MySenderEmailAddress"

Remember, the trick is not really the standard options of the cmdlet, but grabbing the possibly-changing MX record for the relay.  This script will dynamically go and get the *current* first-listed MX record for the recipient, and just use that.

And I can almost hear you now, “…But Jeremy, aren’t you side-stepping the built-in fault-tolerance of the MX record?”  Yes, a bit; you can absolutely add a little more code to this and make it aware of the MX ranking, and roll through them and validate until successful.  Maybe I’ll do that in another post…

By the way, while it may not be obvious to you initially, note that I’m just specifying my recipient’s destination SMTP server as my -SmtpServer.  This *should* be fine in many/most cases.  The destination server should be glad to receive and forward the email to the end user that is a part of its own system.  However, some security protection may block this from happening, so be sure to know your destination first.  In my/our case, this was actually being used in an internal system to a friendly destination.  Your result may vary…

Now get out there and send those emails!

How to simplify Excel formulas with “Cell Naming”…

2017-07-27T00:01:03+00:00 October 31st, 2013|Uncategorized|

This week’s post is about a little-known-feature in Microsoft Excel called “Cell Naming.”  If you ever use Excel, like I do, then this tip is for you!  This is one of those features that I always knew existed but I never actually took the time to try, until now.

Simply put, “Cell Naming” allows you to assign a name to a cell, or a range of cells, for easy reference.  

You can get to the ” Name Manager” from the ‘Formulas’ tab then by clicking on the “Name Manager” button. 

For example:  

Click on the image to get a clear view…


In the above example, you see an Excel worksheet which is 3 columns wide x 14 rows tall that lists sale prices of 10 items at 3 different stores (“Store1″,”Store2″,”Store3″).  Each column has a “SubTotal” at the bottom that adds up the prices of that store’s 10 items sale prices, respectively.  Finally, there is a cell that adds up the 3 different stores “SubTotals” to equal the “GrandTotal.”

Next to the spreadsheet is the “Defined Names” which show you all of your cells/ranges with their associated names.

The four “Defined Names” that I created are:

Store1ItemTotals = $E$4:$E$13
Store2ItemTotals = $F$4:$F$13
Store3ItemTotals = $G$4:$G$13
GrandTotalSales = Store1ItemTotals+Store2ItemTotals+Store3ItemTotals

This was just a simple example, but imagine if you have 1000′s of cells with complex formulas that you need to manage!  And instead of having to manually cross-reference which cells that each formula is calling (i.e “E14″), you can know exactly which is being called by the descriptive “Cell Names” that you’ve pre-applied (i.e. “Store1ItemTotals”).  

I hope this tip will help you save a great amount of time and energy when working with Excel in the future!

Look out – Here comes IE 11!

2017-07-27T00:01:03+00:00 October 17th, 2013|Uncategorized|

For many of us that have been watching the recent pre-releases from Microsoft (Windows 8.1 tomorrow!), IE11 will be a welcome update.  In fact, it will be released as an “Important” update for Windows 7 and up, in order to ensure a large footprint.

However, some companies are barely getting through Windows 7 migrations, or have limited resources available to test their applications against the latest browser, and would like to slow the flow of the river of updates a bit…

So for people/companies that perform automatic updates (or standard deployment of “Important” updates) but *don’t* want IE11 to come down to their workstation, there is a toolkit available to stop the IE11 deployment for Windows 7 or Windows Server 2008 R2 when using Automatic Updates.

Note that for those of you who have used these toolkits in the past for previous versions, the previous toolkits will not stop automatic deployment of IE11, since each uses a different set of registry keys.

Now get that migration done, so you can go to Windows 8.1!!

How to Manage Azure from PowerShell on your PC…

2017-07-27T00:01:03+00:00 September 11th, 2013|Uncategorized|

If you use Azure day-to-day like I do…  and you use PowerShell day-to-day like I do…  then it’s time to put them together like chocolate and peanut butter!  What I mean is, let’s use the power of PowerShell to easily manage your Azure services.

I’ll assume that if you’re still reading this, you have an Azure account (if you don’t, you can get a free trial), and you have a Windows 7 or higher PC or server on which to run PowerShell. 

Install the Azure PowerShell modules
Go to the Azure download page, and at the bottom left, download the “Windows Azure PowerShell” bits and install.  Here’s the direct link to the bits, as of this writing.  It’s just a few clicks and a few minutes to let the web-installer do its thing. 

Once Azure PowerShell is installed, hit Start and type PowerShell to see that you now have another option for PowerShell, called “Windows Azure PowerShell”;  click it! 


Configure the “publishsettings” file

Next we need to link your Azure account with your PowerShell session.  We do this by getting your “publishsettings” file from Azure, and stuffing it into PowerShell.

Run the command: Get-AzurePublishSettingsFile


…This will launch a browser and you will be prompted to authenticate to Azure (if not already).  You will be prompted for download choices, and you should save file to local folder; something like c:tempAppsAzure that I use in the following example.

Next, we import the settings file with the following command: Import-AzurePublishSettingsFile


…of course it depends on what you named the file when you saved it, but this is a standard name format.

Finally, delete the “publishsettings” file — it contains a management certificate file that shouldn’t be left lying around once imported.


…and that’s about it!  You are now linked to your Azure account and can control your world by command.  Let’s start by taking a look at some of the relevant commands:
get-command *azure*

Mmmm…  Those look like fun commands!


Kick the tires

You know, as long as we have an active session, let’s see how I last left my testing lab with a Get-AzureVm command:


…Hmmm…  It looks like I left my Windows Server 2012 R2 “preview” VM shut off.  Let’s start it up with a Start-AzureVM command, specifying the VM name as well as the Service name:


Well, that was fun, but now lunch is over and it’s time to shut down the lab “preview” machine again.  But I just want to shut down the VM for later use, not to de-provision the VM and have to re-create it later.  So, I’ll use the Stop-AzureVM command with the -StayProvisioned flag.


…and so on, and so on.  Now that we’ve got you all set up and have stepped through some basic commands, you should be well on your way to chocolate and peanut butter goodness!

For more detail, make sure to see the Azure PowerShell “Get Started” tutorial:

And for even more detail, view the Azure PowerShell Cmdlet reference guide:

Now *you* go have some fun!




PowerShell v4, and Desired State Configuration…

2017-07-27T00:01:03+00:00 August 7th, 2013|Uncategorized|

For me, the most exiting thing to have come out of Microsoft’s TechEd this year is the new PowerShell v4 feature called Desired State Configuration (DSC).  Being able to deploy countless servers, and be assured that they all will have exactly the products you want installed, the way you want them installed, as soon as you want them installed — all with a few lines of scripting code — is priceless.  I know it’s been a couple months now since it was announced, but if you’re anything like me, you’re just really digging in to the Server 2012 R2 features as you get spare time…  and the power of these new features really start to sink in…

If you want to add a server configured like all the rest?  You add a line in an input file.  You want to add a product to hundreds of servers or change a configuration item?  You add a few lines in what is effectively a PowerShell function.  I just can’t help but think how PowerShell has come sooooo far in making a farm of Windows servers as easy as managing a farm of Linux servers has always been the shell and shell tools, or with certain management tools like Puppet and others!  And the Puppet and Chef folks are on board too, as their products start to make best use of these new capabilities.

For all the info you need to get started (if you haven’t already), make sure to check out the TechEd session, “Desired State Configuration in Windows Server 2012 R2 PowerShell”:

…And also catch up on the blog announcement.  Then, go download the Server 2012 R2 bits and get going!




NTFS Permissions – Copies, and Moves…

2013-07-24T22:37:13+00:00 July 24th, 2013|Uncategorized|

Did you know …

Per Microsoft:  “By default, an object inherits permissions from its parent object, either at the time of creation or when it is copied or moved to its parent folder. The only exception to this rule occurs when you move an object to a different folder on the same volume. In this case, the original permissions are retained.

Okay, so you knew that… but did you know this …?

Per Microsoft: “You can modify how Windows Explorer handles permissions when objects are moved in the same NTFS volume. However, if you want to modify this behavior so that the object inherits the permissions from the parent folder, modify the registry as follows: “


Value name: MoveSecurityAttributes
Data type: DWORD
Value data: 0

And maybe even you knew that….  but did you know it doesn’t always work …?

Actually, this registry value used to work natively with Windows XP (after a reboot).  But for Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2, you must install a Microsoft-supplied HOTFIX to make it work, found here: (

Install the hotfix and reboot.

Also, make sure that the user account that is used to move the object has the Change Permissions permission set.

For the entire knowledge base article, please see:



Publishing MS Word Viewer through Citrix XenApp 6.5…

2017-07-27T00:01:03+00:00 June 19th, 2013|Uncategorized|

Recently, I moved over to the Coretek virtualization team.  It’s a great opportunity to work with new technologies and implement them as part of our Virtual Clinical Workstation solution.  

Citrix is one of the technologies that plays a major part in the solution.  As part of a virtualization implementation we are working on, I was tasked with publishing the Microsoft Office viewers through Citrix XenApp 6.5.  Now, I have a pretty extensive background in software installation and configuration on Windows desktops; however, publishing them through Citrix was new to me.  

The way a published application’s files and registry keys interact with a desktop operating system are fundamentally different.  Therefore, I was surprised to find when I attempted to open a Word document in the published Word viewer by double clicking on the .doc file — the file itself would not open, but the Word viewer would only open up an “Open” dialog.



So, being pretty new to Citrix — and given that it’s a pretty complex application that is comprised of multiple policies, application configurations, and settings, which can redirect content and drive mappings — troubleshooting issues like this can be challenging (and of course, you must also consider all the AD policies applied as well).  In the end, the solution to this particular issue was pretty simple…

Fortunately, once I was able to rule out that content redirection or drive mappings might be the cause, I found a Citrix KB article that addressed the exact issue I was having.  You can read the article here:

In short, I had to add a special parameter (“%**”) at the end of the Word Viewer’s Command Line in the Citrix AppCenter (where published applications are stored).  The default parameter contains only one asterisk (“%*”). 




Hopefully this tip will help if you experience the same issue!




PowerShell – How To Discover and Set Permissions on a Folder…

2017-07-27T00:01:03+00:00 June 12th, 2013|Uncategorized|

I’ve written a few posts here in the past about how to use PowerShell to set NTFS permissions, in a couple different fashions.  But recently I was asked something like, “…okay, I know what permissions I’d like to assign in Windows Explorer, but how do I know what the PowerShell equivalent is?” 

The point of the question is that the description of the permission you see in the GUI is not necessarily what you’d actually put in your PowerShell command when you attempt to apply it.  So how do you know the difference and correlation?

There are tons of references out there for learning more about scripting setting permissions in PowerShell, but it’s not always easy to know *which* permission to set with PowerShell.  So let’s imagine the scenario where we need to add a “custom” permission to a folder via a PowerShell script or command (maybe part of a loop, etc.), and the requesting person has only described to you in the most GUI-like terms what is needed. Step1

In this case, what I usually do is:

1.) Ask the person to set the desired permission on an example folder (if it doesn’t exist already) to be sure that you are talking about the same thing, like this example:

…In this example case we are using the following:

Permission 1: Create File / Write Data
Permission 2: Create Folders / Append Data
Permission 3: List Folder / Read Data
At: Folder name “Bogus”
For: This folder, subfolders, and files
To: LABWorkgroup1


2.) Use PowerShell command Get-Acl .Bogus | Format-List to get a readable ACL from the example folder:


3.) Now, remove that permission from the folder, and run the above command again to see the difference (or just evaluate the SIDs):


…and now you can see — among the other permissions — that the above listed permissions translate to LABWorkgroup1 Allow  ReadData, CreateFiles, AppendData, Synchronize; and the Sddl, if you need it: (A;OICI;0x100007;;;S-1-5-21-2087276962-282213542-3505124996-1115)

4.) Finally, set the permission on the new folder:

$folder = "Bogus"
$myGroup = "LABWorkgroup1"
$acl = Get-Acl $folder
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("$myGroup", "ReadData", "ContainerInherit, ObjectInherit", "None", "Allow")
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("$myGroup", "CreateFiles", "ContainerInherit, ObjectInherit", "None", "Allow")
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("$myGroup", "AppendData", "ContainerInherit, ObjectInherit", "None", "Allow")
Set-Acl $folder $acl

This is a simple example, of course, but it’s an easy way to get it done without chasing down reference documentation.  After a while and frequent use, you begin to kinda’ memorize the various PowerShell permissions options and recognize them — but you can sometimes forget them too, and this is a quick and easy way to figure it out at any time.



Powershell – Check for PS version and act accordingly…

2013-05-22T22:29:39+00:00 May 22nd, 2013|Uncategorized|

In recent posts, we’ve been outlining some important day-to-day differences in PowerShell CMDlets and features between v2 and v3.  And right now I’m working with a customer that is in the midst of transitioning between XP and Win7, and between Server 2003 and 2008/2012, where these differences really start to matter performance-wise. 

So, we’ve got lots of PowerShell tools we wrote in v2 that we are slowly getting around to updating to the new features in v3.  But the thing is, we still can’t be certain where these scripts will be run, and by whom.  So we’ve put together a little “version detector” to help run the correct version of the command and give the best performance possible, whenever possible.  And as a result, you — the reader — can apply this type of thing to any script that might be run in a mixed environment.

This example below features the new -Directory flag in the PowerShell v3 Get-ChildItem, though you could just as easily replace that line in each section with any other CMDlet that behaves differently between versions.  Just modify this section, and wrap it around your CMDlet with the updated v3 capability…


$hostVersionInfo = (get-host).Version.Major
if ( $hostVersionInfo -eq "2" )
  # For PowerShell v2
  write "We appear to be using PS version $hostVersionInfo... That's okay, but this script processes faster with PS v3!"
  write ""
  $containers = Get-ChildItem -path $MoLoPath$CurrentParent -recurse | ? {$_.psIscontainer -eq $true}
elseif ( $hostVersionInfo -eq "3" )
  # For PowerShell v3
  write "We appear to be using PS version $hostVersionInfo... Good!"
  write ""
  $containers = Get-ChildItem -Directory -path $MoLoPath -recurse
  write-host "Unknown/unapproved version of PowerShell. Exiting!"


Normally, I’d explain some of the functionality in the script; but it’s fairly simple, well-commented, and in general pretty descriptive.  It just detects which version of PowerShell you’re running, and runs one of the two version of the CMDlet.  So you should be able to figure it out quickly even if you’re new to this stuff. 

Of course, if you have a question (or have a better way of getting it done), feel free to comment. 

So that’s it, I hope it helps!




Powershell – How recursive directory searches got better with PSv3…

2017-07-27T00:01:04+00:00 April 17th, 2013|Uncategorized|

In the old days, we ate dirt for dinner, brushed our teeth with sticks, used PowerShell v2 — and we *liked* it! 

There, that’s my tribute to Dana Carvey as “Grumpy Old Man”.  Google it, kids.

Anyway, I’ve got an absolute ton of old PowerShell scriptlets that I have lying about that I regularly cannibalize or resuscitate back into production.  And since we are in that squishy transitional period between PowerShell v2 and v3, I don’t always bother to check them for compatibility with v3 or update features in the script to take advantage of new capabilities.  But I hit on one v3 improvement the other day that solved a problem has bugged me so much for so long that I wanted to shout from the mountaintops about it!  And since I live in mostly-mountainless Michigan, the blog is the best I can do…

Really it’s such a little thing.  But it’s so overdue.

In the past, if you wanted to recursively inspect a folder structure on a remote server — for instance while fishing for explicit NTFS permissions on folders — you were forced to inspect all folders *and* files, no matter if you only wanted folders.  Basically, you had to ask for everything (all children folders and files, recursively), then parse the result to extract the folders (check psIsContainer) from the listing.  Here’s an example of this, similar to what you might see all around the internet:

# For PowerShell v2
$containers = Get-ChildItem -path $TopPath$CurrentParent -recurse | ? {$_.psIscontainer -eq $true}

 Of course, this could be incredibly wasteful in processing, network bandwidth, time, etc…   All this time I’ve always wished there was a way in my loops to just ask for ONLY the folders, to save all of that waste.  Thankfully, this has arrived with v3.  Behold:

# For PowerShell v3
$containers = Get-ChildItem -Directory -path $TopPath$CurrentParent -recurse

 This has significantly sped up some of my analysis scripts that I run in a large enterprise, cutting as much as half a day off of some of my execution times (I did mention it was large).  So really what this means is that I have to start spending more spare time looking through the v2/v3 differences…  But I won’t have any spare time until I implement more v3 changes…  Quite a conundrum… 



Load More Posts