Exchange 2010 clear move request fails

In the process of migrating users to Exchange 2010 we will occasionally get an error clearing move requests through the console after they have completed.

Microsoft Exchange Error
Action 'Clear Move Request' could not be performed on object 'user name'.

User Name
Couldn't find a move request that corresponds to the specified identity name'.

We have found these can usually be cleared through PowerShell using Remove-MoveRequest "user name" and you can add -verbose to the end to get details if there are any issues.

HP NC375T Network cards

This is a followup to my slow user login post from last year. We were finally able to figure out what was going on and it turns out it was an issue with our HP/Intel NC375T network card. When in the HP system management web page and the data source was in SNMP mode the card was reporting at 1500 MTU as was everything else we looked at on the system and there were no MTU settings in the registry overriding the default MTU settings. When I switched the datasource to WBEM mode though the card started reporting that it was set at 1486 MTU. This would certainly be a problem since windows wants to send its default packets at 1500.

After much back and forth with HP and them claiming I just need to set my MTU size in the registry to 1500 under HKLM\System\CurrentControlSet\services\Tcpip\Parameters\Interfaces\ their tier 3 support was able to figure out there was a setting in the registry called "*jumbopacket" under HKLM that was set wrong. When we went into the registry this setting was set to 1500 but apparently for this card it needs to be set to 1514. I noticed that on the other card in this system it was set to 1500 and working fine though. Once this was changed and we rebooted we are now able to test ping servers using ping servername -f -l 1472 with no issues.

If you run into this issue the fix seems to be editing the registry. This setting was in multiple places in the registry all under HKLM and were all labeled *JumboPacket (yes there is a * that is not a wildcard) and the setting needed to be changed in the dword default field under the *JumboPacket key and the *JumboPacket dword field in numbered (they appear to all be numbered keys 0000 and up) keys.

Failover Cluster migrations fail

We just added a 3rd node to our Hyper-V failover cluster and everything went great right up until I tried to do a test live migration. I got the ever so helpful
live migration did not succeed at the source.
Ok so going on past experience I know this has usually been the binding order to the adapters not being the same or name of the network adapter being different. So I go and check and everything looks great. The cluster passes verification and the cluster resources list all my network adapters as online and good but still a no go on the migration.

Ok for fun lets try to migrate just the disks and see if i get a more helpful error:
The operation failed because either the specified cluster node is not the owner of the group or the node is not possible owner of the group

Well that error SEEMS more helpful. Unfortunately it led me on a wild goosechase.  I do some more digging and find a more helpful error on the destination machine:
live migration did not succeed at the destination.

Configuration setup for live migration failed on the destination node. Make sure that name of the virtual network is the same on the source and destination nodes, and try the live migration again.
Ok this was interesting since the source machine said the problem was at the source. Long story short after a quick google I found it turns out I was on the right track from the beginning and although all the names looked good in the network connections area it actually cares about the names in Hyper-V Manager/Virtual Network Manager. Once I fixed those it is back to migrating.

Restricting who can login to a system locally

Our company has a bunch of demo room computers that we wanted to limit which accounts had local log in rights on. The solution was surprisingly easy
  •  Login to the machine as an administrator
  • Remove the "<domain name>\Domain Users" from all local groups on the computer (it is default in the "Users" group).
  • Remove any other users from all local groups on the machine that should not have access.
  • Add the domain accounts of the users you want to be able to log on in one of the local groups ("Users", "Power Users, or "Administrators" ).
  • Make sure you leave Domain Administrators in the Administrators group.

Now only the accounts you added will be able to logon to the computer. All other accounts will get a message stating “The local policy of this system does not permit you to logon interactively.”

This of course will not prevent the accounts that do have access from adding more accounts if they have administrative access.

Create multiple distribution groups with powershell and a CSV

So recently I had a need to create over 100 mail enabled enabled security groups for a new application we are rolling out. I really did not want to do this by hand. Powershell it turns out is a great resource for doing this. Create a CSV file with headers (header fields are important!) for example:


Then if your file is c:\newgroups.csv run the following Powershell command

Import-CSV "C:\newgroups.csv" | % { New-DistributionGroup -Name $ -OrganizationalUnit $_.OU -PrimarySmtpAddress $ -Type Security }

This will import your CSV file and parse it line by line replacing each $_ value with the correct value under the header for that line. There is one extra value at the end (-Type Security) that makes every group a mail enabled security group which can be omitted to create distribution only groups.

You can add or remove fields as needed just add or remove the $_ value and create a new header line. You can find a list of acceptable fields by entering Get-Help New-DistributionGroup -Detailed at an exchange Powershell prompt. You can name the header fields whatever you want.

If you just want to create AD groups you can use the following

Import-CSV "C:\newgroups.csv" | % { New-ADGroup -Name $ -groupscope Global }