Migrating ACD from US to EU – CloudHQ to the rescue!
So recently I have been faced with the task of migrating 32Tb of data from Amazons’ Cloud Drive US to their UK Counterpart.
I reached out to Amazon to see if they could facilitate moving the data across, but alas they have no way to replicate data between services!
I considered using my Dedicated server and Rclone, but the 32Tb of data is itself an issue then – Rclone cant do server-side copying because they are technically two different services so it would have to pass 32Tb of data through my Dedicated – which goes against the 30Tb upload limit per month I am restricted to.
So I set about looking at other methods and decided to look at a website-based sync option.
Enter CloudHQ.
Now, I used to use CloudHQ to sync my Google Drive into a folder in my Dropbox (I would put files in Google Drive, let them sync and then let my Ubuntu server drag them out of my Dropbox and repeat as necessary) so I figured why not look to them to see whether I can do this.
Within minutes I had an initial sync going and data traversing over to ACD EU from my US account! Initial sync should take a week or so (and they will email me when its complete), after which I suspect a delta will be made of any changes I make to the US drive in the meantime. Once complete I can take down anything relying on my acd_cli mount, reconfigure and remount in the EU! Perfect!
So, check out cloudhq.net (https://www.cloudhq.net) if you are needing to migrate your ACD US to EU account!
DsReplicaGetInfo() failed with status 8453 (0x2105)
Quick one – if you get the below error when doing a “repadmin /showreps”;
Make sure you are running Command as an Administrator!
VMware, UAG, DirectAccess pt2
Hallo again 
Had some rather nifty issues with a DirectAccess array the other week – so I thought I would return here and blog it!
In short, everything was working fine apart from one very small part – “Manage Out” via IPHTTPS tunnel wasn’t functioning.
In short, clients were connecting the IPHTTPS tunnel before the Teredo was up. Whilst IPHTTPS is connected it will be preferred over Teredo (or 6to4) and disconnects after a random amount of time.
Clients could route traffic down here – so connecting to Intranet services was fine. Tunnel was up on both parts (Intranet/Infrastructure) and everything worked fine apart from “Manage Out”. Routes all fine, Windows Firewall (client-side) all fine.
Queue some hair tearing etc etc.
Raised a call with MS eventually – and in short its VMware causing the issue.
To quote MS (slightly edited to make sense outside of the Email trail);
|
We have had similar cases before where VMWare template provisioning was used for the UAG hosts, and can confirm that the problem was down to the template creating duplicate adapters that would affect tunnel bindings when configuring UAG DA. And the solution was to rebuild using standard media which completely addressed the issue. |
Ouch. Oh well, rebuild we must (I’ll update once they are done!)
Had some other interesting information too regarding VMware, Unicast and DA NLB. I’ll update my original post here
Script to automatically assign Archive users to a retention policy
Quick script that will assign all archive users (i.e. people with an Exchange archive) to a retention policy (that you have created to archive email, obviously). Then runs a “start-managedfolderassistant” to apply.
Obviously “Move after 90 days” is the retention policy name. Tested with 2010 SP1.
Ciao
|
$mailboxes = get-mailbox | where-Object ({$_.ArchiveDatabase -ne $null}) $mailboxes | foreach-object { if ($_.RetentionPolicy -eq "Move after 90 days") { write-output ("User " + $_.Name + " already assigned, skipping") } else { set-mailbox $_ -RetentionPolicy "Move after 90 days" write-output ("User " + $_.Name + " set correctly") } } write-output "Users assigned, starting Managed Folder Assistant" get-mailbox | Where-Object ({$_.ArchiveDatabase -ne $null}) | start-managedfolderassistant |
Retention Policies not applying? Update them then!
When applying a new Retention Policy (or tag) in Exchange 2010 SP1 you may wonder why it doesn’t apply immediately.
In short, Exchange is configured by default to cycle all mailboxes in a 24 hour period. This can be seen (and therefore changed) by looking at the “ManagedFolderWorkCycle” attribute against each Mailbox Server;
get-mailboxserver | select-object Name,ManagedFolderWorkCycle
(obviously, set-mailboxserver to set it – though I believe it only takes day’s as its input value)
If this isn’t good enough – then you can force this on an individual mailbox (or all if you wanted) using the command;
start-managedfolderassistant USERID
(or get-mailbox | start-managedfolderassistant for all)
Happy PowerShelling 
Powershell Command to find component version for Lync and OCS
Came via my Twitter feed;
Handy 
Exchange 2010 RU4 v2 now live
As the title suggests – more details at;
Unable to Seed Database copy–Exchange 2010
Had an interesting issue the other day;
Installing a new 3-node Multi-Role Exchange 2010 deployment – like so;
(for reference, the CAS array will be fronted by a Hardware box provided by the customer – probably a NetScaler or something similar)
Each of the servers was installed – each created the default “Mailbox 00915125” style databases.
Now, typically I rename and move the EDB/Log location for these – it always seems simpler than moving the System-type mailboxes that are located on the first 2010 mailbox database in an organisation. I did so again in this instance, renaming them and moving them to the Mount points created similar to below;
All seemed to be going well – so I created the 3-node DAG (placing the inactive FSW on the vCentre server for later use) and now its time to create myself a secondary copy of one of the six databases.
I ran the usual “add Mailbox database copy” EMC wizard, selecting the second server as a target for a copy of “DB1”. However it copied over the initial EDB file, but wouldn’t copy over any logs (and therefore sat at ~30 logs to copy/replay).
Event log had one error message;
The internal database copy (for seeding or analysis purposes) has been stopped because it was halted by the client or because the connection with the client failed.
Helpful. A Google search turned up This Link – and yes indeed I have SnapManager for Exchange installed (this is a NetApp based deployment after all) – however I am past the version noted (in fact am running the latest 6.0.2.x revision) – and cannot see anything on the NetApp NOW portal regarding this error.
Regardless I removed SME – no joy.
I then tried seeding a second database (after removing the DB1 copy) – and found that out of my 6 databases three wouldn’t seed;
DB1 – formally the default MDB on SERVER01
DB3 – formally the default MDB on SERVER02
DB5 – formally the default MDB on SERVER03
Strange to see but a very clear pattern. So I deleted DB1 and recreated it (initially as DB1 – however this then seemed to inherit the same MailboxDatbaseCopy object in AD so it still didn’t work so I recreated it) as MDB1 and voila it seeded. Even after renaming it back to “DB1” it caught back up (and I tested it for failure heavily later on – note to self btw – do NOT delete the boot disks from the vSphere server on an Exchange 2010 deployment. They do come back – but its not pretty and makes you sweat!).
So in short, if you are having problems seeding a Database to a second node, and it is the default created with Exchange 2010 SP1 – delete and try again.
(For reference these servers were installed with 2010 SP1 and then updated with RU3 v 3)
RU4 for Exchange 2010 SP1 removed…
Just a quick one – as the title Suggests Microsoft recently pulled RU4 for Exchange 2010 SP1 due to a new-found bug.
The current answer is one of two things;
1) Uninstall RU4
2) Apply the Interim patch for RU4 (KB 2581545). You will have to ring Microsoft for this (as it is not yet published) – however be warned that initially this KB number will not seem to exist. Best bet is to raise a call with the Exchange team (you will have this refunded as it is a bug/fix situation) – however I had to get to third-line Exchange guys before I got an “Yes, it’s here”. Also bear in mind that this will likely have to be removed before RU5 can be applied (when it is released).
Take care!
(For my own sanity I posted this as a comment ;
Problems authenticating to ActiveSync? Don’t be an Admin then!
Recently had the following error when testing ActiveSync (via www.testexchangeconnectivity.com after the IT manager said their Android device wouldn’t work 
)
I did a bit of digging and found out something I did not know – if you are a member of any BUILTIN Administrative group in Active Directory then you cannot utilised ActiveSync!! (This is due to the “Inherit permissions” removing as you are a member of a “Protected Group” from what I could gather).
Oh well, time to remind people that they should not be using Domain Administrative accounts for day-to-day access!!! 
Ramblings of a Geek 