I just installed Azure Devops 2019 on my server. I can access the devops server fine through the web portal but when I try to connect using VS 2019 - team explorer - manage connections - Add Azure Devops Server I get a error "TF400324: Azure DevOps Service are not available from server http://xx.xx.xx.xx:8080/tfs."
I also see that VS add :8080/tfs to the IP I add. But thats not the correct adress. When using Team Foundation Server this adress was valid but Azure Devops does not use the same.
So how can I connect to the new Azure DevOps server from VS 2019?
So how can I connect to the new Azure DevOps server from VS 2019?
You can try:
1.Close all VS instances and then clean VS cache(%LocalAppData%\Microsoft\VisualStudio\16.xxx\ComponentModelCache) and TFS cache(%LocalAppData%\Microsoft\Team Foundation\xx\Cache).
2.Go to Control Panel -> User Accounts -> Manage your Credential -> Windows Credential, select the VSTS url to remove it.
3.Restart VS to re-connect to Devops server.
In addition:
1.Make sure you enter the correct URL. In VS if I don't enter correct URL of tfs instance, I would get this error:
2.Many factors can cause TF400324, just like above. So it could be better if you can share more details about your TF400324, remote name not resolve,Could not create SSL/TLS secure channel or what.
I had issues connecting to DevOps. I was using https and http. The trick for me was to "Change Public URL" in the "Azure DevOps Server Administration Console". This was done on the "Application Tier". Once I had this done the redirect for HTTPS worked because it used a fully qualified DNS name that matched the certificate I was using.
If you are not using HTTPS, then you may just have a DNS server issue. Check the DNS settings on the client PC and use something like ping or nslookup to see if the server name resolves to the correct IP address.
Related
when i try to register with the authentication keys, im getting the below error
enter image description here
It seems you hit some network issue. Maybe you can check if you have whitelist azure's IP range.
A connection to the service back end is not possible for the self-hosted IR. Most often, the firewall, DNS, or enterprise network settings are to blame for this problem.
To resolve this
Check to see whether the integration runtime service is running. if it is running and no proxy is configured on the self-hosted IR run the below command in your Windows PowerShell, I will give you glimpse of error.
Code from Microsoft document
(New-Object System.Net.WebClient).DownloadString("https://demofactorypratik.eastus.datafactory.azure.net/")
You can get the above link form Integration runtimes > your self-hosted IR > Nodes > View Service URLs.
Expected result:
If you get a "Remote name could not be resolved" message, there's a DNS issue. if you get an "ssl/tls cert is not trusted" message, then install the public certificate by using Certificate Manager. Go to Event viewer (logs) > Applications and Services Logs > Integration Runtime, here you can find check what's the exact issue.
I can successfully be able to connect Self-hosted IR
Also see, Self-hosted IR connectivity issues
I have an Azure SQL server where I wish to deploy my database via dacpac using GitHub CI/CD. I am using the Azure SQL Deploy action with Service Principal for Azure login action
Due to policy restrictions on the client side, the "Deny Public Network Access" is always enabled and therefore while deploying even though the service principal login works, the GitHub action is unable to add the IP Address to the firewall rule.
We are using Self-Hosted GitHub runners. Is there any workaround to deploying the database via CI/CD under such circumstances where we cannot add the firewall rule to whitelist the agent/runners IP Address?
The solution was to do away with Azure Login action and add self-hosted runner virtual network in the Azure SQL Firewall settings:
The Azure Login action attempts to add IP Address of the runner to the Azure SQL Firewall. Hence, this action must not be used. I removed this action and relied on the second step for seamlessly accessing Azure SQL Database instead.
The Azure SQL Deploy action requires either above login step or "allow access to azure services" to be turned ON. Both of which were not an option for me. I decided to go with an action that runs sqlpackage.exe. https://learn.microsoft.com/en-us/sql/tools/sqlpackage/sqlpackage-publish?view=sql-server-ver15
I am using self-hosted runners which are hosted within the virtual network configured within Azure. However, the point that I had missed was to add the virtual network to the Firewall settings in Azure SQL. Once, I did that, I did not require an explicit login or whitelisting runner ip addresses.
Im new to devops , and im trying to deploy windows service to on premises vm,
I have added Copy file from task and setup all the user name/ password/ source/ destination and all the required settings.
but error
[error]Failed to Create PSDrive with Destination:
'\my_server\D$\TestCI', ErrorMessage: 'The network path was not
found'
fails the release.
can you help on this?
Since you work on the Azure Devops Server，you should be using self-hosted agents.
ErrorMessage: 'The network path was not found'
The casue of this issue could be that the Self-hosted agent and the Target windows machine are not in the same Windows Domain.
To solve this issue, you could try to create a new self-hosted agent under the same windows domain (the machine which in the same local network), then grant the permissions for the build agent service account to access another local PC.
Here is the ticket with the similar issue, you could refer to it.
My cluster is using Windows Authentication for client to endpoint and it works as expected in browser when connecting to cluster by prompting to use username/password to connect to SF console.
I'm confused as far as what I'm supposed to put into publish profile in Visual Studio. There is no option to choose Windows Authentication anywhere, only cert and Azure Active Directory. How is it supposed to work?
Using WindowsCredential="True" in the publish profile should work. Here is a powershell version that has worked for me in the past.
Connect-ServiceFabricCluster -ConnectionEndpoint:':19000' -WindowsCredential:$true -TimeoutSec:60
I am using VSTS (Visual Studio Team Services, formerly known as Visual Studio Onine) for continuous deployment to an Azure VM using an Azure File Copy task in my build definition.
The problem I am having is that I have an ACL setup on the Azure VM that is only allowing connections from my office for Remote Powershell.
With the ACL in place, the Azure File Copy task fails with an error like "WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that the firewall exception for the WinRM service is enabled and allows access from this computer." With the ACL removed, everything works.
To be clear, this is not a problem with WinRM configuration or firewalls or anything like that. It is specifically the ACL on the VM that is blocking the activity.
So the question is, how can I get this to work without completely removing the ACL from my VM? I don't want to open up the VM Powershell endpoint to the world, but I need to be able to have the Azure File Copy task of my build succeed.
You can have an on-premises build agent that lives within your office's network and configure things so that the build only uses that agent.
https://msdn.microsoft.com/library/vs/alm/release/getting-started/configure-agents#installing
Azure File Copy Task need to use WinRM Https Protocol, so when you enable the ACL, the Hosted Build Agent won't be able access to the WinRM on Azure VM and that will cause Azure File Copy Task fail.
When copying the files from the blob container to the Azure VMs,
Windows Remote Management (WinRM) HTTPS protocol is used. This
requires that the WinRM HTTPS service is properly setup on the VMs and
a certificate is also installed on the VMs.
There isn't any easy workaround for this as I know. I would recommend you to setup your own build agent in your network that can access to Azure VM WinRM.