The 2 hour version of this is what I've always done in actual interviews, except where we peer develop the solution together the whole time, and I let the candidate drive and lead as much as they want to.
The take home version might be useful beyond that, but I've found that solving some fun toy problem like, "let's build a little app for X" in a couple hours you absolutely know if the candidate can code and have a good feel for what it would be like to work with them.
I think it's different from an exam because the candidate is working on their own laptop, with their own tools, with full access to Google, StackOverflow, etc.
If for some reason they don't have a portable dev environment I guess we could provide it but that does hamper the process somewhat because it's not really "in their element" anymore.
I don't know how you really prepare for such an interview, other than actually having the portable dev environment and being well rested.
The only thing we use the whiteboard for is understanding the problem statement and sketching out the steps to creating the solution, as in, things a whiteboard is actually meant to be used for.
The take home version might be useful beyond that, but I've found that solving some fun toy problem like, "let's build a little app for X" in a couple hours you absolutely know if the candidate can code and have a good feel for what it would be like to work with them.