I am trying to send email using one of our on-premises servers from one of my web roles hosted on azure. We've got a Windows Azure Connect endpoint installed on this on-premises server which has an SMTP server.
We've configured the web role so that it contains an activation code I acquired using the windows azure portal and the azure subscription we have. The web role has been deployed to azure with this configuration. Looking in the virtual network section of the portal I can see our on-premises server listed as well as the instance of said web role. I Created a group connecting the local endpoint to the web role instance.
The problem I'm having now is figuring out exactly what I have to do in order for the emails I send from the web role to be relayed through the smtp server on the on-premises server.
My first thought was to just specify the local endpoint name as it appears in our azure portal as the host to use when I create my SmtpClient object in code. Of course this didn't work as I received an SmtpException just saying Failure Sending Email.
So my question is once I've set everything up as described above, what do I need to do in ,my web role code and/or configuration in order to use the local endpoint as the smtp host for sending out my emails??
How about open your firewall for the SMTP on both your azure VM and local server.
As I know the azure VM firewall disabled the PING (ICMP) but doesn't know if it blocked all ports except those defined in your CSDEF file.
Related
We are getting below error on Azure devops pipeline via Self hosted agent release when Azure web app is on Private network. No Error seen when the web app on azure is on Public.
Error: Error: Failed to deploy web package to App Service. Error: tunneling socket could not be established, statusCode=503
Made Azure web app to private and error comes. Moved to public no error seen.
Seems that the self-hosted agent cannot connect to the Azure app service. It seems to be a network issue.
The agent needs a way to connect to the App service directly. To ensure the connectivity is ok, we need to make sure the self-hosted agent is not blocked by NSG rules or App Service networking Access Restrictions. Just whitelist the agent machine in your rules.
The task using Kudu REST API to deploy the application. We need to check the following App Service networking Access Restrictions to allow deployment from a specific agent:
Make sure the REST site “xxx.scm.azurewebsites.net” have Allow All, i.e. no restriction.
Also, the option “Same restrictions as ***.azurewebsites.net” should be unchecked.
If you are using Private Endpoints for Azure Web App, you must create two records in your Azure DNS private zone or your custom DNS server. Kindly check DNS for more details.
Besides, when the proxy is set up, Web API calls and SCM hosts are bypassed by the user. The same has to be configured in the Azure pipelines agent explicitly. To bypass specific hosts, follow the steps here and restart the agent.
1.Allow access to Public removed.
2.Created Pvt endpoints within same Vnet and Subnet of Target VM
3.Created new file .proxybypass in self hosted agent folder C:\Username\Agent
4.Added below entries in .proxybypass to allow and communicate bypassing corporate proxy
https://MyWebappname.azurewebsites.net
http://MyWebappname.azurewebsites.net
enter code here
I want to register a target using a registration script generated by Azure DevOps. My production server does not have an active internet connection, will the registration script work?
If not what Url's do I need to specify in the proxy to allow that communication?
You'll need to be able to access the URL for your azure-devops account to register an agent. You can also reference this documentation for whitelist addresses.
I have two servers , Server #1 one hosted in the office using the office network (this hosts the tableau server on ubuntu server) and the other server Server #2 sitting in another collocated network. The web application is hosted in server #2 and the tableau dashboards are embended on the web application.
When I try to access the application from another public network , the dashboards are working very well, however when I try to access the dashboards from the office network (which hosts the tablueau server ), I get the following error =>
That error is generally caused by one of two issues
The IP Address of Webserver hosting the IFrame was not whitelisted under Trusted Authentication in TSM or Add Trusted IP Addresses or Host Names to Tableau Server
or
The trusted user does not exist on the Tableau server and/or the username does not match what was passed to the webserver from your web application hosting the Iframe.
We have trusted_ticket_expiry set to 240 minutes.
https://kb.tableau.com/articles/issue/changing-the-expiration-timeout-of-trusted-tickets
We host a website in our company.
A certificate was issued to www.ourdomainname.com from the company IT department.
Now we want to move the website to azure and install the certificate there.
I already exported the certificate with private key exported set to true from the server.
1.) What will happen when the certificate is installed on azure when it is also installed on our company server?
2.) What will happen when the website on our server is stopped in the server and the certificate is then imported to the azure website?
3.) How can I guarantee a soft transition time without any break?
The aim is:
Website on the company server going to be deleted and the website on azure is used instead.
What will happen when the certificate is installed on azure when it is also installed on our company server?
web site will be available via SSL in Azure too.
What will happen when the website on our server is stopped in the server and the certificate is then imported to the azure website?
web site on your server will be inaccessble.
How can I guarantee a soft transition time without any break?
it is more about DNS management. There is no much work with SSL. You just install SSL on both internal and Azure servers, so clients can access both. Test if web site on Azure works the same way as on your internal server. Then point all clients (via DNS) to a web site on Azure. When all clients move and there are no references to internal server, you can safely shutdown it.
The SSL Certificate which was exported from the current server has to be imported in Azure. The format of the certificate has to be PFX.
Now, in the DNS Management , you need to edit the A record for the URL and point it to the IP address of Azure. This will make sure that any request made will be handled by Azure .
I wanted to create a Test rig on cloud. I have created a windows azure hosted service that installs Test Controller and configures it with on premise DB. I have created another hosted service that installs Test Agent. I have enabled Virtual network in the Azure service by providing Activation token taken from azure portal. I also created a Azure Connect Group in which I added my local endpoint(On Premise DB) and windows azure roles( Test Controller rand Test Agent). When I deploy this on azure I am facing problem of Test Agent connectivity with Test Controller.
Test Controller can ping to my on premise DB machine and vice versa. But my test controller machine cannot ping test agent machine or vice versa on cloud.
I have ensured following things on test Controller
User testagent is part of group TeamTestAgentService
User testagent is also administrator on TestController hosted service.
Firewall exceptions have been added
If I try to ping two azure machines I cannot do that. By default azure has ping disabled so I added following firewall rule
netsh advfirewall firewall add rule name="ICMPv6" dir=in action=allow enable=yes protocol=icmpv6
but it still does not work. I think if these two machines will be able to ping each other the problem of test agent connectivity to test controller on cloud will be solved.
Reply from http://social.msdn.microsoft.com/profile/rlfh/
It won’t work as you have it now. The controller and agents have to be in different roles, but also the controller you need to install Azure Connect as an endpoint– not enabled as a role. So, you want to configure the Controller manually, then it should show up so you can add it to the Connect From list. Leave the agents as they are(azure connect as a role) and then it should work. The Roles in the Connect TO: part won’t be allowed to intercommunicate, though an endpoint can – since they have the option you selected to allow this.
My problem was solved when I manually installed Azure Connect endpoint from azure portal on the controller machine instead of enabling it as a Role in Virtual network.