To echo was Kostia asked -- can you provide the error? I was the creator of the sandbox and have probably reserved it ~150 times since it went live.
The error that you're receiving around licensing is expected. DCNM has some demo licensing that we're utilizing for this sandbox and you should have full functionality in the sandbox even when it says you're out of compliance.
Now -- the lack of synch is another issue. If the DevNet_Fabric is discovered correctly (from the topology view, the switches will be grey, but the interconnect lines will be green; from the tabular view each device will show as being "ok"), DCNM has found the backing topology (instantiated inside of CML2), which is required. DCNM uses the serial numbers of the devices as the "key" for the database, and those serials change with every instance reserved, so DCNM loses itself for a second until everything comes back online and then it just assumes that things have changed. A by-product of this that we must do a "re-synch" to reconcile the state of the devices against what is stored within the DCNM database. This is why the devices are grey within the topology view, because the state is unknown.
If you're performing a resynch -- and the devices come back as "red" or out of synch -- you can figure out what is going on by clicking on "save and deploy" in the upper right hand corner of the topology view. DCNM will perform a deep synch and compare against the applied configuration on each switch. This may take several minutes -- but will return a window showing what needs to be changed within each device to make it "compliant" with the database config. I have a hunch that it is out of compliance with four lines. If you click the link under the "4 lines" on each device -- it will show that the default route for the mgmt VRF needs to be removed. This happens every now and then within the reservations -- and I've not been able to pinpoint why (I've worked with TMEs and we haven't isolated the case since we're not using DCNM as it should have been used, since we're changing the devices on the fly).
If this is indeed the case, you have two options depending on what you'd like to do. One causes the devices to conform to the config database, the other causes the database to conform to the devices.
(a) You can complete the save and deploy action and remove the 0/0 route. This will cause the devices to remove the route, meaning that you can't access the devices directly from your VPN workstation, only the jumphost in the sandbox.
(b) I have published a repository for sample code that will accompany the learning labs that I'm writing. This has a fix for this issue and will push new "policy" to DCNM, which will add the 0/0 route to the config database and cause the devices to show up in synch.