We are using Azure to Azure Site Recovery for our Virtual Machines, but when we fail them over and re-protect, the Virtual Machines are cleaned up (removed), but the NIC still remains (and still has the Static IP associated with it). How do we clean up the VM?
As a bit of background we use a script to associate Public IP to the NIC when failing over based on this: https://gallery.technet.microsoft.com/scriptcenter/Add-Public-IP-and-NSG-to-a6bb8fee
Is it possible the fact we change the NIC (associate NSG and Public IP) means that azure doesn't delete it?
How can we delete it automatically? I can't see a way to run a post-script on re-protect.
Related
CentOs 7 with whm
Compute Engine VM Instance was working fine and GCP given external static ip xx.135 and internal 10.xx.x.2
Upon checking it is found that network settings was DHCP hence I
modified /etc/sysconfig/network-scripts/ifcfg-eth0 with BOOTPROTO=static with static ip given by GCP and restart network service. After that I lost the
control of VM. What is wrong? How to resolve the issues and get the control?
I do not think you needed to modify the DHCP configuration. You could follow the link here for Reserving a Static External IP Address. Also, this is the documentation if you would like to Reserve a Static Internal IP Address.
The way to fix a messed up config like this is to use the console, where the user can revert that config. Just to note here that you might have to have set the password. This is, in fact, one way.
Another way is if the disk attached is a Persistent Disk, you could attach it somewhere else and replace the config. Here is the documentation for that. There is a caution, some types of VMs that won't allow for this. It won't work if it's a local SSD.
I'm having trouble creating a network link between my Hyper-V host machine and its VM (both are running Windows 10).
I created an virtual external switch for both the host and VM so that both can access the internet and download programs and Windows updates, but I could not get them to communicate with each other directly. My research told me to create a virtual internal switch in Hyper-V and then have the devices be able to access each other that way (presumably by doing something like typing \\host_machine_IP\c$ into an explorer window once the network connection had been made). But once I created the virtual internal switch and assigned static IP address to both the host and VM on it, I still could not ping the host from the VM, or vice versa.
Am I missing a step? Let me know what more details you guys need.
By default you would have Windows Firewall blocking your communications until you confirm network profile to be other than Public. Try selecting a home\work network location profile via Control Panel > Network and Sharing canter. Or disable the firewall on the machine you try connecting to. Otherwise you should have no communication problem with the setup described, provided the subnet is the same for both machines.
I have deployed my ASP.NET WebForms application (Azure Web Role) on Azure virtual network. I have been told by the IAAS team that the subnet which I have used needs Proxy XX.XX.XX.XX:8080 for accessing the application from the internet. If it's a virtual machine I can add proxy xlass, but I am not able to add the proxy class in service configuration file and added it in application web.config, but still it's opening from public internet and not able to connect to RDP.
Please help me with this.
Thanks
RDP wouldn't require a proxy that I'm aware. I imagine you match the same config as mentioned here to set your ACLs (too many images and not enough text to copy here)
http://blogs.msdn.com/b/walterm/archive/2014/04/22/windows-azure-paas-acls-are-here.aspx
If you really are trying access for RDP check out the following. If just web access, the above should work.
http://www.cloudcomputingadmin.com/articles-tutorials/windows-azure/azure-virtual-networks-and-cloud-services-part3.html
As per
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-rdp-detailed-troubleshoot/
Source 3: Cloud service endpoint and ACL
To eliminate the cloud service endpoint and ACL as being the source of issues or misconfiguration for virtual machines created using the Service Management API, verify that another Azure virtual machine that is in the same cloud service or virtual network can make Remote Desktop connections to your Azure virtual machine.
If you do not have another virtual machine in the same cloud service or virtual network, you can easily create a new one. For more information, see Create a virtual machine running Windows in Azure. Delete the extra virtual machine when you are done with your testing.
If you can create a Remote Desktop connection with a virtual machine in the same cloud service or virtual network, check for these:
The endpoint configuration for Remote Desktop traffic on the target virtual machine. The private TCP port of the endpoint must match the TCP port on which the Remote Desktop Services service on the virtual machine is listening, which by default is 3389.
The ACL for the Remote Desktop traffic endpoint on the target virtual machine. ACLs allow you to specify allowed or denied incoming traffic from the Internet based on its source IP address. Misconfigured ACLs can prevent incoming Remote Desktop traffic to the endpoint. Examine your ACLs to ensure that incoming traffic from your public IP addresses of your proxy or other edge server is allowed. For more information, see What is a Network Access Control List (ACL)?.
To have public internet connectivity into your worker role you need one of the following:
A public IP address (https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-instance-level-public-ip/) associated to the worker role instance (or)
A public endpoint configured to expose a specific port (https://azure.microsoft.com/en-us/documentation/articles/load-balancer-overview/)
If you use Network Security Group, please ensure that you have appropriate ACLs opened up to allow connection from Internet.
Thanks
Im building out an Azure hosted website, but it needs to reach into our home office to connect to some internally hosted web services. Our firewall is setup to only allow traffic over certain IP's, so we're looking to determine what IP range we need to allow access to.
Currently I'm still using the MSDN "Free" Azure subscription, so I don't know what options may be limited, but is there a way I can determine what source IP, subnet, whatever my Azure hosted site will attempt to call my web services from?
Thanks!
Be careful opening your firewall to the entire Azure datacenter IP ranges. Anybody can host anything in Azure, including malicious software, so if you open your firewall to the entire Azure IP range you may as well just open to 0.0.0.0-255.255.255.255 because in effect you are getting the same security.
A better option is to deploy your service and just whitelist that one IP address. That IP address is guaranteed to remain the same until you delete your service. With the ability to do in-place upgrades and VIP swaps there should be no reason why you would need to delete your hosted service and lose your IP address. If you ever do run into a scenario where you need to delete/redeploy you can always update your firewall at that time.
It sounds like this is what you're looking for:
Windows Azure Datacenter IP Ranges
I'm new to Azure Networking and not very familiar with Networking in general, so pardon my naivety.
My requirement is to set up a Windows Domain, which I understand is the phrase used to describe a network whose principals (machines, users, services etc) are tracked via a centralized database (usually Active Directory).
I understand that this can be done on Azure, and I can add virtual machines provisioned on Azure to this network. However, I would also like my laptop (and possibly other machines my team and I own) to be a part of the same network.
Is this possible on Azure?
Would I require a device as mentioned here to set up something like this?
What I need this setup for is so that I can create an environment that allows us to replicate the environment our clients have (typical Corporate Windows Domains with Active Directory, Exchange Server etc). So even if the above is possible using Azure, but there are more effecient alternatives, I would love to know about them.
Thanks
Jaspreet
What you really need is to create a virtual networking set in which you will add virtual machines on Windows Azure as well as physical machines from your on premise network.
To keep machines under one domain you can have domain controller (DC) running in Windows Azure Virtual Machines, or you can keep running DC on premise and connect with Azure Virtual Network.
Once you have DC established and you will have VPN based networking connection between your on premise machines and Azure VM. So when you bring your Laptop or any physical machine which is same Domain joined (DC in cloud/on-premise) then machine will be authenticated through the same DC which u have configured earlier. Keep in mind that any physical machine which is already domain joined will show up in same network as soon as your domain controller is configured with Azure Virtual Networking. That's all you need.
Here are step by step details for you to follow:
Creating and Settings up a Virtual Network in Windows Azure
Adding a Virtual Machine to Virtual Network at Windows Azure
Install a new Active Directory forest in Windows Azure
OR
Install a Replica Active Directory Domain Controller in Windows Azure Virtual Networks
https://www.windowsazure.com/en-us/manage/services/networking/cross-premises-connectivity/