We recently noticed that we had a user with 516,000 contacts in his mailbox. Many of them duplicated hundreds of times. We figured out this was an issue that other people had seen when switching from one mobile device to another. Mostly it seems from a BlackBerry to an Android. For some reason this has caused some users to experience a massive replication of contacts. I did not delve much into why as this had stopped already but we needed to clean up his current contacts. He had already tried to manually do it but this was not working.
It turned out the easiest way to clean up the contacts was to have him backup 1 copy of the correct contacts and then run the following PowerShell command.
Search-Mailbox -Identity "<user name>" -SearchQuery kind:contacts -DeleteContent -TargetMailbox "<logging mailbox>" -TargetFolder "SearchAndDeleteLog" -LogLevel Full
This command will search the <user name> mailbox for all contacts and delete them. This process will be logged into the folder SeachAndDeleteLog in the account you specify in <logging mailbox>
After this completed (about 3 hours) we had him replace his saved contacts.
Search-Mailbox replaces the old Export-Mailbox with deletecontent in Exchange 2010.
More information on Search-Mailbox can be found at http://technet.microsoft.com/en-us/library/dd298173.aspx
You can find information on advanced querying here http://msdn.microsoft.com/en-us/library/aa965711%28v=vs.85%29.aspx
Hyper-V specified node is not an owner or possible owner
Recently I added a 3rd not to our Hyper-V cluster which uses cluster shared volumes. After this I started seeing errors when trying to live migrate or backup with BackupExec some of the VM's. The error was:
"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"
This error is from BackupExec but the error from live migration is almost exactly the same. Looking at the VM's they all appeared to inherit the new cluster node correctly so it was not obvious what the issue was. After a bit of digging I finally figured out the problem was with the cluster shared volumes they had not added the new node as a possible owner. The normal volumes had though. to determine if this is the problem you can run the following PowerShell command:
cluster.exe res "<cluster disk name>" /listowners
e.g. cluster.exe res "test disk" /listowners
To add owners use the following command
cluster.exe res "<cluster disk name>" /addowner:<new owner>
e.g. cluster.exe res "test disk" /addowner:node3
There is no GUI option for viewing or setting these that I have found.
"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"
This error is from BackupExec but the error from live migration is almost exactly the same. Looking at the VM's they all appeared to inherit the new cluster node correctly so it was not obvious what the issue was. After a bit of digging I finally figured out the problem was with the cluster shared volumes they had not added the new node as a possible owner. The normal volumes had though. to determine if this is the problem you can run the following PowerShell command:
cluster.exe res "<cluster disk name>" /listowners
e.g. cluster.exe res "test disk" /listowners
To add owners use the following command
cluster.exe res "<cluster disk name>" /addowner:<new owner>
e.g. cluster.exe res "test disk" /addowner:node3
There is no GUI option for viewing or setting these that I have found.
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
Failed
Error:
Couldn't find a move request that corresponds to the specified identity domain.name/user name'.
--------------------------------------------------------
OK
--------------------------------------------------------
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.
--------------------------------------------------------
Microsoft Exchange Error
--------------------------------------------------------
Action 'Clear Move Request' could not be performed on object 'user name'.
User Name
Failed
Error:
Couldn't find a move request that corresponds to the specified identity domain.name/user name'.
--------------------------------------------------------
OK
--------------------------------------------------------
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.
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
Ok for fun lets try to migrate just the disks and see if i get a more helpful error:
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 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.Ok this was interesting since the source machine said the problem was at the source. Long story short after a quick google I found http://support.microsoft.com/kb/2475761 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.
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.
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
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.”
- 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:
name,OU,email
group1,mydomain.com/distrogroups/ou1,group1@mydomain.com
group2,mydomain.com/distrogroups/ou1,group2@mydomain.com
group3,mydomain.com/distrogroups/ou2,group3@mydomain.com
Then if your file is c:\newgroups.csv run the following Powershell command
Import-CSV "C:\newgroups.csv" | % { New-DistributionGroup -Name $_.name -OrganizationalUnit $_.OU -PrimarySmtpAddress $_.email -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 $_.name -groupscope Global }
name,OU,email
group1,mydomain.com/distrogroups/ou1,group1@mydomain.com
group2,mydomain.com/distrogroups/ou1,group2@mydomain.com
group3,mydomain.com/distrogroups/ou2,group3@mydomain.com
Then if your file is c:\newgroups.csv run the following Powershell command
Import-CSV "C:\newgroups.csv" | % { New-DistributionGroup -Name $_.name -OrganizationalUnit $_.OU -PrimarySmtpAddress $_.email -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 $_.name -groupscope Global }
Subscribe to:
Posts (Atom)