Many times Azure Virtual Machine instances have behaved very differently. Once, there was an automatic update which took 4 days non stop to update and in other time the every single setting for the port and firewall was fine, but couldn’t do a RD for that instance.
I am writing up this blog post to illustrate what I do every time before start deploying a Virtual Machine Instance.
Actually each instance has a logical firewall guarding for the port protection, they are operating at the instance level i.e. hypervisor level. In Azure management portal it is under the ENDPOINTS tabs. To enable communication to the instance via a particular port, it is mandatory to open the port here in the portal. We will specify the a friendly name to identify the endpoint, the protocol [ TCP, UDP ] and the port / port range.
This guard is sufficient and effective for the instances. By default the Windows firewall is active and we need add the port or program in firewall’s exception to enable access. So with all the basic settings in place, in order to setup and web server using IIS, one must open the ENDPOINT 80 TCP in the Azure Management Portal, then again in Windows Firewall. This essentially means that we are doing the same redundant operation at various levels.
Having the entire security setting in a single place is good enough. So I turn off the firewall and leave the PORT security responsibility at the hypervisor level.
I have written a separate blog post to Solving IE Content Block Alert in Windows Server. It is quite annoying for an administrator to keep adding ever single URL to exception before accessing the site. One can turn off of the IE Enhanced Security setting during the deployment and later turn on the Security Setting again if required
By default the automatic updates are turned on which means the instance can search & acquire for the Windows Update anytime and then install and restart. This puts the instance in a risk of downtime and not accessibility for a period of time ( actually considerable amount of time/days in my case ).
All administrators are aware of the update process and management however, if the instance is managed or administered by a DevOp this is something to note. Turn off the Windows update, if there is any specific update required, one can always search for a particular update and instance.
It is very risky if the automatic update is turned on and which means if the architecture is deployed on a single instance, during the update process the entire application goes offline during the operation.
There are public port and private ports available in Windows Azure Virtual Machines and this is mainly used in the scenarios of multiple instances / distributed deployments. If the deployment is going to be on single instance, it is better to have the private port same as public port as the default public port as the Windows Azure assigns AFAIK in somewhat like 43421. The port ranges generally lie outside the the organization’s firewall limit.
Hope this will be useful for someone who are getting started with Azure Virtual Machines