It seems you did a good job getting the same functionality using AES. The problem is that Microsoft is not using good practices themselves.
They confuse a password with a key, and they do not use a good key derivation function such as PBKDF2 (implemented in .NET by the class RFC2898DeriveBytes). This you should only use if you do not have access to a shared AES key, which can just consist of 16 cryptographic random bytes.
Furthermore, they did not use a random IV. The IV has the right size (the block size of the block cipher) but it has been set to a constant value. This means all the security benefits of having an IV are negated. The IV should be a cryptographic random (or at least fully unpredictable to an adversary), and could be written in front of the ciphertext (e.g. by supplying it to the unencrypted stream). Static IV's are only secure if the AES key is randomized or if the plaintext is sufficiently random itself.
They use UTF-16 (incorrectly called Unicode in .NET) to create plaintext bytes from the input. UTF-16 uses 16 bits for each normal character, instead of the 8 bits used by UTF-8. So their encoding method is not very efficient.
Note that if you want to use this in a communication protocol that you may need to add a MAC to protect the integrity and authenticity of the plaintext. If you do not, you may even loose the confidentiality of the plaintext (as the default CBC mode of encryption is vulnerable to padding oracle attacks).
So good job, cannot say the same thing of Microsoft.