Is what i'm trying to do safe?
This is a very difficult question. But first the standard information:


Don't roll your own crypto if anyhow possible. (which isn't the case here)
No protocol should be considered secure until formally proven secure. (TLSv1.2 is)


That being said I can still provide "ad-hoc" security argumentations why it's likely that your handshake is (in)secure.I can't prove protocols secure. For this need you have to consult special companies or cryptographers who have actually published such proofs.


If a protocol downgrade (which is trivial here) doesn't hurt you you should be safe.
Your encryption key currently is $EK=KDF(KDF(MS||SHA_{256}(MS||Ver||Rand))||Rand)$. I think that just deriving this key like $EK=KDF(MS||Rand)$ is equally secure and a bit faster and you can expand it to $(EK||AK)=KDF(MS||Rand)$ with $AK$ being the authentication key.
The generation of the session ID like this is a nice idea to authenticate the random value at the same time (maybe using the suggestion below).
I'm not fully sure what you mean by this question. But the Rand value is essential to be different each time to get different session keys (what your protocol tries to achieve), so hardcoding them would be a very bad idea.


Some other notes:


You mentioned HMAC for authentication. Please use a standard AEAD construction (->GCM,EAX,...) if anyhow possible.
You may want to consider, if sending the SessionID, that you check the SessionID on the client side, as it is an "authentication tag"
You may also want to consider using a different IV/Nonce for each message and exclude it from the handshake as it doesn't seem to provide any purpose. However, after the handshake it's an interesting idea to exchange random messages to check the key exchange worked.
You may further want to consider replacing the SHA-256(MS||Ver||Rand) by $HMAC_{MS}(Ver||Rand)$ and thus "authenticate" the random value and the version to defend against tampering, this means you also need to actually transmit the tag (which you were already doing).
You may want to consider using a TLS-PSK cipher suite, like TLS_PSK_WITH_AES_256_GCM_SHA384, but then you'd loose the session key property of having different keys as all session keys will be equal (somewhat defeating the purpose of your protocol), but you could use the "other_secret" field to insert some random negotiated data (using your above protocol) and be confident that you use "fully" TLSv1.2 and have key-freshness.