I googled and searched but no use. I have VNet which is already created in Azure Classic Portal and I want to add a subnet gateway and a gateway in PowerShell to connect it to an existing IaaS v2 Vnet. How can I do that in PowerShell? Please let me know if there's any resources on how to do that.
Thank you
According to your description, if you want to connect the VNets in different deployment models. The most important is that, the address ranges for the VNets do not overlap with each other, or overlap with any of the ranges for other connections that the gateways may be connected to.
Also your PC have installed the last PowerShell cmdlets, make sure you install both the Service Management (ASM) and the Resource Manager (ARM) cmdlets. Now we can create the VPN to connect the VNets in different deployment models.
More information about how to connect VNets in different deployment models, please refer to the link below:
https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-connect-different-deployment-models-powershell/
If you still have questions, welcome to post back here. Thanks.
Related
I am deploying Tabular Model via CICD, using this approach , however every time it deploys using different IP addresses. I have to disable the firewall rule in Azure Analysis Services for deployment. Is there any workaround for this or a specific IP range to whitelist?
For Self-hosted agent:
You can configure one specific Self-hosted agent for deployment purpose, so that you only need to add the IP address of the agent machine to allow list.
For Microsoft-hosted agent:
And if you prefer to using cloud-hosted agents, you need to dynamically modify the firewall rule in each continuous deployment.
(Since every time you get a new hosted agent instance, you then get a different IP address.)
We can use a Azure Powershell task right before the deploy task to configure the firewall rule of your Analysis Service. About how to write the content of PS script, you can refer to AddDevOpsIpToAAS.ps1 for some help.
Here's one detailed blog from Arthur about "How to add your DevOps IP to Azure Analysis Services Firewall", it should be helpful for you. (Thanks to Arthur!)
Over the years, I used No-IP to link a domain to my IP address, and then used No-IP's DUC (Dynamic Update Client) to update my IP, so that the domain will always point to my IP.
That's very handy for running dedicated game servers.
Is there a DUC-equivalent for Google Cloud DNS?
In essence - No - there isn't :(
Unless yo're using Google Domains for your domain hosting then yes - they support just the thing.
Cloud DNS doesn't have that functionality. There are several workarounds like reserving a public IP for your VM which in my opinion would be the best way to do it. Unless your VM get's deployed using Deployment Manager then it may require some more scripting.
Similar questions have been raised on Stackoverflow here and here which you might find helpful.
If you're running Linux here you'll find a complete script how to update DNS records after a machine startup.
I have deployed a VNET on Azure. I have also set up a Point-to-Site connection following this tutorial. I need 3 things on this Network.
VM Instance for MongoDB Docker.
WebApp API(ExpressJS) which should treat (1) as local address
Connect my Local machine to VNET to manage my VM Instance
I managed to deploy (1)
I successfully connect my machine (3) to the VPN and can access (1) on local IP 10.1.0.5:PORT using Mongo DB Management tool.
For WebApp API (2). I have followed all the necessary steps mentioned here. And Azure Portal show that the App is connected properly.
According to this video I should be able to connect the VM (1) . However I cannot access the local resources from the WebApp API (2).
My Connection String for WebApp API(2) is of the following format:
mongodb://[username]:[password]#10.1.0.5:[port]/[db-name]
What can be the possible reason?
since this seems to be specific to your setup, I would recommend reaching out to support so the support team can do a thorough investigation.
-- Anavi N [MSFT]
I've recently upgraded an on premise Service Fabric cluster to 5.1.156.9590 running on Windows Server 2012 R2. I removed the original cluster and created a new one. Unfortunately my new cluster doesn't seem able to create the firewall rules for any ports specified in the service manifests. The only warning I see that seems connected is this from the ServiceFabric Hosting:
Did not enable firewallpolicy for current profile 1
I can't find any help regarding this message. I'm wondering if something has changed as regards specifying ports for a service or there's something on the node boxes that I haven't configured correctly.
Any pointers appreciated as I'm sure I didn't have to open them manually previously.
Unfortunately, I had the same problem and didn't succeed in reanimation of Service Fabric. Only moving to Azure helped to resolve the issue. You can try next things:
Completely remove SF, SDK, related services, firewall rules and directory SFData on C drive, then install everything again.
Check that firewall is enabled
Check that SF service is created and able to start
If the service is not able to start, check events, there is a special folder for SF where you can find additional and detailed infromation
If you have customized the address on which listeners will listen in SF cluster config, try to change it on something different and see if SF would deploy or not
I have a domain controller set up in an Azure VM, and a couple of other servers also set up as VMs. When I set up the server VMs, I configured DNS and WINS to point to the IP address of the DC and joined them to the domain. However, these settings don't survive a shutdown (where the VM is deallocated). When the VM is started back up, DNS and WINS are empty, and domain authentication does not work.
I read that I should provision new VMs via PowerShell commandlets, specifically setting up domain joining. I tried that, and maybe I got something wrong, but it didn't work -- the newly provisioned VM was not joined to the domain, and did not have DNS/WINS set to point to the domain controller.
In any event, my question is: is there any way to re-configure an existing VM to retain network settings through a shutdown or is my only option to figure out how to provision a brand new VM to be married to the domain controller, and then to start from scratch?
Thanks!
You shall never use static configuration on your Azure VM! Neither for IP Addresses, nor for DNS Settings. What I recommend to use is a long story you can read here. It is tested, validated and proven to be effective. A short extract follows:
You should setup at least two sub-nets. Leave one solely for the DNS (and AD/DC if it happens to be the same server). Put all rest of the machines in the other Sub-Net. Thus, you will have 100% predictable IP Address of the DNS Server machine. Having that in mind, configure the DNS for the virtual network via the portal or via PowerShell. But explicitly configure DNS Server for that virtual network. Set IP address for the DNS - the one that you know it will have!
Please do never forget - never manually change network configuration settings for an Azure VM! Doing so is a path to failure.
The above method will help you resolve DNS issue. Now, for the WINS. I don't think you can configure WINS via Virtual Network settings. So, if your VM really loses WINS config, you can create a small powershell script that runs locally on each VM to configure WINS settings upon boot. You can either make this script more generic by looking up the DHCP assigned DNS server and use the same IP Address for WINS, or just put it static, because you know what the IP Address of DNS server will be.
Anton presents a clever and perfectly workable solution, but I wanted to understand what exactly I was doing wrong, because Microsoft guidance suggests that it should be perfectly possible to set up and maintain an Active Directory domain the in the Azure cloud without putting the DC into its own subnet.
After a lot of trial and error (mostly error), I finally figure it out. This is not well documented, so hopefully this will help someone:
In Windows Azure, cloud service is another term for application, or a set of components that scale together. A cloud service is assigned a single DNS name and a single external IP address. In the context of virtual machines, you typically have a 1:1 correspondence between a cloud service and a virtual machine. You only add additional virtual machines to an existing cloud service when you want Azure to automatically load balance and distribute requests among the VMs inside that cloud service, treating them as if they were one.
This brings me to my mistake. Not fully understanding the above, I was attempting to add a new worker virtual machine to the cloud service in which I set up my Domain Controller. That is not a supported configuration. Once I understood that, and properly configured a new VM into its own cloud service, associated with the domain controller as DNS server, everything worked perfectly.