It replicated. What more do you want? :)
I once had a similar thing happen when I added a new server to an existing DFS Replication group on Windows Server (two words that I've always said don't sit comfortably together). DFS-R very quickly and efficiently replicated the nice, capacious new storage volume to the other servers. (Hey, I could save some money on disks! No need to buy several new ones when we run out of space: just buy one and replicate it! Why didn't I think of that before? :-P )
Thankfully, the data on that particular replication set was not mission-critical (it was mostly multimedia content) so it was merely inconvenient for the day or so it took to restore from the previous night's backup and re-replicate to the group.
Since then, I've always pre-seeded new servers using Robocopy. DFS-R still insists on replicating the whole lot in one direction or the other (exactly which way seems to be totally random) when the server joins the group, causing massive fragmentation (this is NTFS, after all, where writing a 1MB file to a freshly-formatted 1TB disk will probably result in at least 60 fragments), but at least the losses are, at worst, limited to any changes saved to an existing server since the files were copied over to the new machine.
I should have done this anyway the first time, just as I would have with NTFRS, but DFS-R was shiny and new and supposedly much more reliable (my a**e - there's a reason I held off migrating SYSVOL from NTFRS to DFS-R until Server 2012R2 migration forced my hand) and I thought it would be kind of cool to be able to just "set it and forget it" and watch it sort itself out without me having to lift a finger. Why did we bother upgrading to Server 2003R2 if not for the greater ease of administration? (Of course I'd also forgotten that, even if replication had gone the right way, the new server would immediately start advertising itself as a good place for the clients to find their content, despite most of it not yet having been copied over.)