Tag Archives: powershell

Using cluster.exe with Hyper-V 2012 R2

I have a newer 2012 R2 Failover Cluster on which I was not able to move one of the Cluster Shared Volumes. I kept getting an error indicating that no other node could own the CSV:

Error draining node / moving CSV to another node
Error draining node / moving CSV to another node
"Error Code: 0x80071398 The operation failed because either the specified cluster node is not the owner of the group, or the node is not a possible owner of the group"

So I searched online and found website after website indicating that I needed to use cluster.exe in order to add my second node as a possible owner of the CSV, with the following syntax:

cluster resource “csv_a1” /listowners

I was not able to use cluster.exe and eventually found that it had been deprecated.

Error when running cluster.exe in Server 2012 R2
Error when running cluster.exe in Server 2012 R2

It took me a while of searching and using the wrong PowerShell cmdlets to find this post on Installing the Failover Cluster Feature and Tools in Windows Server 2012

In the blog post it indicates that you can install the Windows Feature RSAT-Clustering-CmdInterface which “Includes the deprecated cluster.exe command-line tool for Failover Clustering. This tool has been replaced by the Failover Clustering module for Windows PowerShell.”

Well I already had the Failover Clustering module for Windows PowerShell installed, and I couldn’t figure out how to make this second node a possible owner of the CSV, so I installed RSAT-Clustering-CmdInterface to use cluster.exe

Installing RSAT-Clustering-CmdInterface to use cluster.exe
Installing RSAT-Clustering-CmdInterface to use cluster.exe

Once this was installed I was able to use cluster.exe to add my second node as a possible owner of “csv_a1”. Then I could drain the Node, and finally reboot it which was what I was trying to do before running into this issue.

Hopefully this helps someone else with Windows Server 2012 R2 Hyper-V Failover Clustering if they have this issue and are also getting errors when trying to use cluster.exe

Safe Senders GPO Not Working

We had a GPO for Safe Senders in Outlook that was supposed to pull the Safe Senders from a text file shared on the SYSVOL, but it was not working.

I looked into Exchange 2010 to figure out how I could do Safe Senders at a server level rather than have to configure a GPO for it.

In the Exchange 2010 Management Console I navigated to Organization Configuration | Hub Transport | Transport Rules

Exchange 2010 Management Console - Transport Rules
Exchange 2010 Management Console – Transport Rules

On the Transport Rules tab I added a New Transport Rule:

Adding a new Transport Rule to Exchange 2010
Adding a new Transport Rule to Exchange 2010

When the wizard launches, it is very self explanatory and is built like an Outlook rule.

New Transport Rule Wizard
New Transport Rule Wizard

I selected to enable this new transport rule for the condition “when the From address matches text patterns” so I could add the domains I wanted to whitelist.

textpatterns

I added appriver.com$ as my text pattern. I used a dollar sign at the end of the text pattern because of what I read on TechNet:

The dollar sign ( $ ) character indicates that the preceding pattern string must exist at the end of the text string being matched. For example, contoso.com$ matches adam@contoso.com and kim@research.contoso.com, but doesn’t match kim@contoso.com.au.

Since I know that everything I want to whitelist from AppRiver comes from @appriver.com I use the $ character in my text pattern.

After clicking OK and then Next, it’s time to figure out what Action to perform when a message matches this text pattern.

What do we want our Transport Rule to do?
What do we want our Transport Rule to do?

I chose “set the spam confidence level to value” and then clicked on the underlined blue text link in order to set the SCL to -1. This ensures that Outlook does not classify the message as spam and put it in the Junk E-mail folder.

On the next page of the wizard I did not enter any Exceptions because I want this transport rule to be active for all messages coming in to my organization from AppRiver.

Now the rule is complete. But as always, there are other ways to do it rather than using the GUI. As in most cases, you can use PowerShell!

This is the output that we see on the last page of the New Transport Rule Wizard, which we can translate into a PowerShell command:

Name: 'Safe Senders'
Comments: ''
Priority: '0'
Enabled: $true
FromAddressMatchesPatterns: 'appriver.com$'
SetSCL: '-1'

Translated into a working PowerShell command:

New-TransportRule -Name "Safe Senders" -Comments 'Safe Senders list to whitelist specific domains' -FromAddressMatchesPatterns: 'appriver.com$' -SetSCL: '-1'

Since I already had this rule set up, I modified the string to create a test transport rule:

New-TransportRule -Name "Safe Senders Test" -Comments 'Test List Made From Powershell' -FromAddressMatchesPatterns: 'ericrdu.com$' -SetSCL: '-1'
Creating a New Transport Rule via PowerShell
Creating a New Transport Rule via PowerShell

If you don’t want to enable your new Transport Rule right away, add in -Enabled $false to your command. Otherwise the rule will be enabled by default.
You can also add a -Priority X (where X is a number) to set the order in which your rules will be applied. Since this is my first rule, I do not need a Priority and the default will be 0. Any additional rules will be added as +1.

So now, does the rule actually work?

Held Spam Report email header from earlier in the day, before the rule (because the Held Spam Report comes from AppRiver):

header1

Held Spam Report email header after adding the rule:

header2

Using Notepad++ to add multiple users to a Distribution List

During the latest snowstorm here in Raleigh we had the need for a new distribution group so that we could communicate between a select group of people who were working from home.

I used PowerShell to create the Distribution Group with the New-DistributionGroup cmdlet

new-DistributionGroup -Name 'Remote Workers' -OrganizationalUnit 'mybiz.local/Groups/Distribution' -SamAccountName 'Remote Workers' -Alias 'RemoteWorkers'
set-DistributionGroup -Name 'Remote Workers' -RequireSenderAuthenticationEnabled $false
Sidenote: I set RequireSenderAuthenticationEnabled to $false because I wanted this group to be accessible to Internet emails. If I wanted it to be internal only, I would not bother with running this command. I learned quickly with Exchange 2010 that when a new distribution group is created it makes this value $true which prevents emails being sent to the group unless the user is authenticated (a member of your domain).

Now that the group was created, I needed to add approximately 30 users. Fortunately someone had created a spreadsheet detailing these particular users, with columns including:

Last Name, First Name, Mobile Number, Work Extension, Department, Title, Email Address

While I could use some Excel functions to make usernames out of Last Name + First Name, the easiest option here was to use all of the email addresses with a PowerShell command.

I copied the email addresses into Notepad++. To turn this into a PS cmdlet that we can run in the Exchange Management Shell we need to insert  the Add-DistributionGroupMember cmdlet before all of the email addresses. I could manually paste this on each line, but that would be annoying. And manual. After adding this to each line I also have to put a closing quotation mark at the end of each line to close the email address value. So if this was for 100 or 200 people, or even 1,000 people if your environment is that large, it would take a long time and a lot of keystrokes.

I would rather spend some time now figuring out how to automate this so that when I need to perform this in the future I can do it with ease. This is where the awesomeness begins!

Now that we’ve pasted our email address list into Notepad++ with each email address on its own line, follow these instructions to turn it all into lines of PowerShell code:

  1. Press CTRL + H to bring up the Replace window
  2. check off “Regular expression” at the bottom left
  3. put a caret ^ in the “Find what” field (this is the regular expression for “the beginning of each line”)
  4. in the “Replace with” field enter the following:
    Add-DistributionGroupMember -identity 'Remote Workers' -member "
  5.  Click “Replace All”

Your Notepad++ window should now like this:
Note that there is a quotation mark before each email address

Output after using Notepad++ "Replace All" to add code to each line
Output after using Notepad++ “Replace All” to add code to each line

We aren’t done yet, as we have to close each line with a quotation after the email address.

  1. In Notepad ++, put a dollar sign $ in the “Find what” field (this is the regular expression for “at the end of each line”)
  2. in the “Replace with” field enter a quotation mark “
  3. Click “Replace All”

Now you have a full line of PowerShell code that should look like this:

Add-DistributionGroupMember -identity 'Remote Workers' -member "user1@mybiz.com"

Copy the entire Notepad++ window and paste this into your Exchange Management Shell to add all these users to the distribution group:

Output of Exchange Management Shell after pasting in code from Notepad++
Output of Exchange Management Shell after pasting in code from Notepad++

Don’t forget to press Enter for the last line. Since there is nothing following it, the shell will not process the command automatically as it did with all the previous lines.

Check your distribution group to see that it has its new members and be on your way to the next IT solution!

 

Renaming Windows Firewall Rules with PowerShell

I had some rules that were set by default that were not “user friendly” so I wanted to rename them in order to be able to tell what they were without having to query.

I can use Get-FirewallRule with some parameters to see the rules in question:

get-netfirewallrule -displaygroup "remote desktop" | format-table name, enabled -autosize
Use get-netfirewallrule to view the current firewall rules
Use get-netfirewallrule to view the current firewall rules

Then I Mark (right click, “Mark”, select and press the “Enter” key to copy to clipboard) the GUID and get the name of that rule to see what it is:

Get-NetFirewallRule -Name {4F5F06CB-CA8A-4676-BDB3-4BBBC8E95481}
Viewing the details of the firewall rule in question
Viewing the details of the firewall rule in question

Then I rename the rule using the Rename-FirewallRule cmdlet, and query again to see the change:

rename-netfirewallrule -name "{GUID}" -newname "New name of firewall rule"
get-netfirewallrule -displaygroup "remote desktop" | format-table name, enabled -autosize
Renaming the firewall rule to match the DisplayName attribute
Renaming the firewall rule to match the DisplayName attribute

As it turns out, these rules are duplicates of the ones above – the only difference that I found was that they apply to different profiles. The rules with “user friendly” names were for the “Public” Firewall Profile, whereas the GUID rules were for “Domain” and “Private” Firewall Profiles. This is the way the Remote Desktop rules are added when you configure Remote Administration with sconfig. This relates to my previous post on “Installation Configuration: Hyper-V Server 2012“.

Differences between the builtin rule and the rule created when using sconfig
Differences between the builtin rule and the rule created when using sconfig

 

 

Installation Configuration: Hyper-V Server 2012 R2

Upon first boot of Hyper-V Server 2012 R2 you are presented with a blue Server Configuration window

sconfig window in Hyper-V Server 2012
sconfig window in Hyper-V Server 2012

This window is called automatically by the system but it can be found in C:\Windows\System32

(Read more about Sconfig.cmd here: http://technet.microsoft.com/en-us/library/jj647766.aspx)

If you closed the window you can always access it via command line by typing:

sconfig
tip
Helpful tip for Core mode: If you closed the command prompt and have nothing on the screen, press CTRL + ALT + END
 

Even after enabling Remote Management, I was not able to connect to my server via RDP. I enabled ping in the sconfig Network Settings to ensure that I could see the server from my desktop, and while ping was successful I still could not open a RDP session to manage my Core installation.

I figured it was the firewall, so I disabled it completely:

netsh advfirewall set currentprofile state off
netsh-firewall-off
Turning off the firewall with netsh

After turning the firewall off in its current profile I was able to successfully remote in to my Hyper-V Server 2012 R2 installation and finish up my settings.

Since this is a home lab setup, I am fine with the firewall being off. In a domain environment, you might turn the firewall off as well (depending on your security protocols).

*******

At first I did not want to disable the firewall completely so I went down the path of figuring out why I could not RDP to my server. This turned out to be somewhat of a challenge.

I started by checking out the Remote Desktop rules. This command will return the name of the Remote Desktop rule and whether it is enabled:

get-netfirewallrule -displaygroup "remote desktop" | format-table name, enabled -autosize
List of firewall rules that are part of the "Remote Desktop" group
List of Windows Firewall rules that are part of the “Remote Desktop” group

If we had run this command prior to using sconfig to enable Remote Desktop, we would only see the first three rules. The second three rules are added and enabled when we use sconfig to enable Remote Desktop. The first three rules are not enabled, but the GUID rules are enabled.  Why did sconfig create three new rules to enable Remote Desktop?

You can see here that the GUID rule (the first in the image, after I renamed it from the GUID to match the DisplayName) matches the second rule shown: “RemoteDesktop-UserMode-In-TCP” (no spaces), except for the Profile attribute, which for the GUID rule (top) is Domain, Private and for the built-in rule (bottom) is Public.

Caption TBD
GUID Rule (top, renamed), Built-In rule (bottom)
(Read my post on renaming firewall rules with PowerShell)

Still, Remote Desktop is not enabled, so we can enable the three rules that are not enabled:

enable-netfirewallrule -displaygroup "remote desktop"
Enabling all rules in the "Remote Desktop" group
Enabling all rules in the “Remote Desktop” group

Another check of the rules:

Now all rules in the "Remote Desktop" group are enabled
Now all rules in the “Remote Desktop” group are enabled

Remote Desktop rules are all now enabled and I was able to successfully RDP to my server!

These steps would be the same for the full version of Windows Server 2012 R2 Core Edition Standard or Datacenter.

But WHY?!

I ended up figuring all of this out after a re-install of Hyper-V Server 2012 R2. What happened was that sconfig added the firewall rules for RDP (the GUID rules), but it added them for the Domain and Private firewall profiles. My server was set on the Public profile. Therefore, the rules that were added via sconfig were not applicable. Why does this happen out of the box? I suppose that is a question for Microsoft.

In the end I simply added the Domain and Private Profiles to the built-in rules, then enabled the group as above. I did NOT enable Remote Desktop with sconfig because I did not want it to add those three “extra” GUID rules. I suppose if you were going to have multiple connections using different firewall profiles then you would want separate rules, but this is for a lab setup and I like to make things less confusing!

In order to add the Domain and Private profiles to the built-in firewall rules, I used the following command. I included the Public profile just to be complete, even though it is already part of that rule:

set-netfirewallrule -name remotedesktop-shadow-in-tcp -profile Domain,Private,Public
Add Domain and Private profiles to the existing firewall rules
Add Domain and Private profiles to the existing firewall rules
All firewall profiles are now part of the built-in firewall rule
All firewall profiles are now part of the built-in firewall rule

Now repeat this command for your other two rules:

RemoteDesktop-UserMode-In-TCP
RemoteDesktop-UserMode-In-UDP

Happy Administration!