I've tested Schema updates in lab by performing the steps above, by using P2V processes, and a couple other routines. Anytime I've ever seen problems it was always related to the fact that the offline lab has some AD related issues due to the process of trying to duplicate the environment in the first place. Realistically you'll end up spending a lot of time trying to create a duplicate lab, as if you have multiple sites, domains, tree, etc you need to clean up a lot of that stuff in the offline version. Also, you can never duplicate the intricacies of the actual production environment, so odds are that whatever problem you might possibly run into in the production forest would not appear in a stripped down test forest anyway.
But not once have I seen a problem caused by extending a production Schema for Exchange or OCS or other MS products. This is a fairly safe procedure that seems to scare some IT management, probably due to the irreversible nature of it.
Also, regarding the process above, I would never pull a DC offline, make changs, and then add it back to the network later on to replicate those changes. What you should do in that scenario is to deploy a new DC, take offline, seize roles, apply Schema updates, etc. If it works, then great, kill that box, remove it from the prod DC by cleaning the metabase up with the NTDSUTIL so that the server is removed compeltly from AD. Then simply perform the Schema updates on the production network as instructed by the guide.
