Archive

Archive for April, 2011

Cleaning up Distribution Lists after a Quest migration

April 19, 2011 Leave a comment

I noticed the other day that the Quest imported DL’s are a tad messy – lots of “userid.postoffice.domain” references.

 

Wrote the following to clean it up – should work without too much butchering into your own environment (but test first!)

 

$list=get-distributiongroup -ResultSize Unlimited
$global:progress = $list.count
foreach($line in $list){
$groupname = get-group $line
$emailaddress = $groupname.DisplayName
$emailaddress = $emailaddress.replace(" ","")

set-distributiongroup -Identity $line.DisplayName -EmailAddressPolicyEnabled $false
set-distributiongroup -Identity $line -SamAccountName $emailaddress -WindowsEmailAddress "$emailaddress@domain.local" -EmailAddresses "$emailaddress@domain.com"
set-distributiongroup -Identity $line.DisplayName -EmailAddressPolicyEnabled $true
$i++
Write-Progress -activity "Changing DL’s" -status "Percent complete: " -percentComplete (($i / $progress)  * 100)    
}

Remove Disabled mailbox

April 19, 2011 Leave a comment

Quick one – a little PowerShell to remove a user who you have Disabled.

Get-MailboxStatistics –Database DATABSE| where {$_.DisplayName -eq "Users Name"} | foreach {Remove-StoreMailbox -Database $_.Database -Identity $_.mailboxguid -MailboxState Disabled}

 

Note, this could be changed to the following;

Get-MailboxStatistics –Database DATABSE| where {$_.DisconnectedReason -eq "Disabled"} | foreach {Remove-StoreMailbox -Database $_.Database -Identity $_.mailboxguid -MailboxState Disabled}

 

Which *should* remove all Disabled mailboxes in the DATABASE specified (I haven’t tested this, only the single user one (I also only tested in 2010 – but the same premise should stick for 2007 too))

Ding! (100 posts)

April 18, 2011 Leave a comment

I just realised that this is post 101 – meaning I have passed the 100 post count!

 

image

 

Ok, time to move this thing forward – I need regular posts (I know) and weekly summaries of anything that’s a bit more. I’m still thinking of how to achieve this, so watch this space Smile

 

In the meantime, another cloud (I like the source site, may even find some way to add this in regularly)

 

image

Categories: Blog, News

RPC Timeout when adding DAG node

April 18, 2011 Leave a comment

http://social.technet.microsoft.com/Forums/en-GB/exchange2010/thread/1a709b6b-ba35-47f4-9919-cd474fa44912

Recently had a customer with a WAN-split DAG – in short the first node was in the UK and they wanted a second node in Singapore adding.

 

Got the following error message;

 

Add-DatabaseAvailabilityGroupServer -Identity DAG -MailboxServer SINGAPORE
WARNING: The operation wasn’t successful because an error was encountered. You may find more details in log file
"C:\ExchangeSetupLogs\DagTasks\dagtask_add-databaseavailabiltygroupserver.log".
A server-side database availability group administrative operation failed. Error: The operation failed with message: Error 0x71a (The remote procedure call was cancelled) from cli_RpccAddNodeToCluster
    + CategoryInfo          : InvalidArgument: (:) [Add-DatabaseAvailabilityGroupServer], DagTaskOperationFailedException
    + FullyQualifiedErrorId : BC0535B9,Microsoft.Exchange.Management.SystemConfigurationTasks.AddDAG

 

In short, this was due to a the link between myself and Singapore being too slow – which confused me slightly as I thought it had been uplifted in 2010.

 

A quick call to the Microsoft partner helpline, and I got this cleared up;

 

In RTM the RPC timeout is 5 minutes – also DAG links must be <250ms ping on average (to be supported)

In SP1 the RPC timeout is 10 minutes – also DAG links must be <500ms ping on average (to be supported)

 

Sorry Mr Customer, your on RTM Sad smile

Quest Error Log PowerShell

April 18, 2011 Leave a comment

Some handy PowerShell cmdlets to parse out nastily long Quest NDS Migrator logs Smile

 

 

Select-String finalerror.txt -Pattern " Error  " | select Line | Format-Table -Wrap | Out-File errors.txt

Select-String finalerror.txt -Pattern "(The process cannot access the file because it is being used by another process)" | select Line | Format-Table -Wrap | Out-File err-inuse.txt

Select-String finalerror.txt -Pattern "(Invalid path, or path too long.)" | select Line | Format-Table -Wrap | Out-File err-toolong.txt

TMG, UAG, DirectAccess, Unicast NLB and VMware… phew!

April 18, 2011 2 comments

 

A Customer of mine utilise ESX 4.1 to host their UAG and DirectAccess solution.

 

VMware KB article 1006778 (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006778) dictates that for a Unicast NLB to function within VMware, the following statements must be true;

  • Need two machines running Windows Server 2003 or later
  • Each machine needs to have at least one network card and at least one fixed IP address
  • Two adapters in each machine is recommended for best performance
  • One adaptor mapped to the real IP Address (Microsoft calls this the Dedicated IP) and one mapped to the ‘virtual’ IP Address (Microsoft calls this the Cluster IP)
  • One benefit of unicast mode is that it works out of the box with all routers and switches (since each network card only has one MAC address)
  • In unicast mode, since all hosts in the cluster all have the same MAC and IP address, they do not have the ability to communicate with each other via their NLB network card
  • A second network card is required for communication between the servers

As UAG Direct Access requires an internal and external NLB there are, by default, no none-NLB interfaces. This is contrary to the requirements set by VMware, so we must define a tertiary NIC just for NLB and TMG array communication.

This has been applied as per the following diagram;

clip_image002

Each UAG server has had the tertiary NIC defined as can be seen above. These are configured with a private IP range.

This should be enough to make Unicast NLB work Smile If not, drop me a line as I have some further steps I put in (that I don’t think are required)

 

UPDATE: After speaking with Microsoft on something entirely different it has come to light that the above solution, although workable, is fully NOT SUPPORTED by Microsoft. In short the only supported solution for Microsoft is to have both UAG servers on the same VMware host (in which scenario you don’t require the Intra-Array link). Note that this is also the case currently for Multicast scenarios (which supposedly is supported generally and still waiting for a Technet update)

Categories: Microsoft, TMG 2010, UAG 2010

Exchange 2010 SP1 Unable to Move Mailboxes?

April 18, 2011 2 comments

Recently had a weird one – when trying to move a mailbox on a fresh Exchange 2010 SP1 RU2 install, I got;

"ERROR: There are no available servers running the Microsoft Exchange Mailbox Replication service."

image

 

For some reason, installing at SP1 didn’t warn me that I had not set the NetTCPPortSharing service to Automatic. Setting this to auto, starting it, and then (re)starting the Mailbox Replication service sorted me out Smile