Mandatory user profiles have been around for some time now, since Windows XP, in fact. For those who aren't familiar with this venerable Windows mechanism, mandatory user profiles are roaming profiles that have been configured with specific settings that are typically not able to be modified by the end user logging on to the Windows machine. Further, any changes to the profile that do get made (for example, malware) are not saved back to the mandatory profile. They are a one-way street of configuration. These are great for education machines: testing centers, writing labs, and also kiosks sometimes fit a mandatory profile requirement.
When a server hosting the mandatory profile is unavailable (network issues, remote host away from the corporate LAN, and so on), a locally cached copy is loaded (if it exists, this is configurable). If the profile is not cached locally, a temporary profile can be served or the login can be rejected (via Group Policy).
Mandatory user profiles are, by and large, normal user profiles; the NTuser.dat has just been renamed to .man (for mandatory), marking the profile read only. The process is documented in detail on TechNet so we won't repeat it here (and it is, in theory, subject to change anyway from build to build in the WaaS model).
One concern of mandatory profiles is login times. If you thought copying a profile across the network from a central host (even DFS or other replication) would make the user wait, you are in fact correct. It does. And a poorly configured mandatory profile (or even roaming profiles that aren't mandatory) can be a huge cause of Slow Boot Slow Login (SBSL) problems in the enterprise. Microsoft has provided this policy grid to demonstrate what policy functions to use depending on the version of Windows:
