I'm currently running into an issue that is occurs when my Visual Studio TFS Server deploys a test agent to a remote server. According to documentation:
You will need a minimum of two machines - a target server or virtual
machine to deploy to, and an agent machine that drives the
deployment. [Check]
You should use an agent machine that is in the same domain and
network as the target server(s). Communication from the agent to Team
Services or TFS is over HTTP/HTTPS, while communication from the
agent to target server(s) is uses the WinRM protocol. [Partial Check
Our TFS server is located on domain Awhile our target server is ondomain B.]
This is according to the documentation for deploying ASP.NET apps to domain-joined machines using WinRM.
To limit the scope closer to the actual issue I'm having is that the deploy process seems to fail once configuration begins for the test agent. More specifically TestAgentConfiguration.ps1 PowerShell script that is ran on the TFS Server when being deployed to the target server. The requirements for this specific script as described on the github page is:
.NET 4.5 on Windows7 SP1 or Windows 2K8R2 [Check]
Test machines should have PSRemoting enabled (run 'Enable-PSRemoting'
on Windows Powershell) ###WinRM setup This task uses the Windows
Remote Management (WinRM) to access domain-joined or workgroup,
on-premises physical or virtual machines. [Check - This command seems
to only run once the machine has the firewall turned off (after a
reboot). Our domain group policy disables Windows Firewall by
default, so when running the above PowerShell command it works.
However, if we enable the firewall (which seems to fix my issue) for
the initial configuration of the TestAgent then the command no longer
works both with and without the firewall. This is only fixed once
rebooting the server]
We have followed documentation based off what is presented on the Support Additional Help pages. However, I'm still confused on why the working solution for this deployment process requires Windows Firewall to be enable for any part of the configuration as on the Pre-Requisites says "There is no inbound communication from Team Services or TFS to the agent, or from the target server to the agent. This means that you do not need to open any firewall ports on the agent machine, but you do need to open the WinRM port on the target server(s)."
I'm under the impression that since our environment is on two separate domains (A & B) where domain B trusts domain A there are some additional steps that are checked with the firewall. However, with the configuration step failing during deployment when the Firewall is disabled, it will pass with the Firewall Enabled. Any further consecutive runs/deployments with the Firewall then disabled still pass making the initial Firewall check useless.
I have each step's "TestAgentConfig.log" described in the summary which is saved on the target server for each step in the attempts that I made, however due to my post I'm limited to a certain limit of characters.
Summary:
Fresh reboot of target server, kicked off a build with the Windows
Firewall Turned Off --> Build Fails
On that same server without a reboot, turned on Windows Firewall
--> Build Successful
On that same server without a reboot, turned off Windows
Firewall --> Build Successful
Related
I am trying to debug an app, using Visual Studio 2017, that I will run on a virtual machine I've set up on my development system. The virtual machine runs Windows 10 (as does my development system).
I've installed the latest VS 2017 Remote Tools package on the virtual machine, and configured it. It is happily running on the virtual machine...but I can't connect to it from the desktop system.
When I do an attach to process, and a Find to find the system, the virtual machine is found.
However, after selecting the virtual machine, I am prompted for credentials. I've tried using the same login credentials I use to log onto the virtual machine, but that doesn't work. And there's no information shown as to what might be the problem.
The virtual machine is running under Hyper-V.
How do I go about setting up a remote debugging connection to virtual machine running on the same system where I am running VS 2017?
I ran into the same issue and managed to get it working, after much effort.
First, try switching the debugger authentication mode to "No Authentication" (Tools -> Options) and setting your project in Visual Studio to match (see the language-specific links in the MS docs link below). That will help you determine if it is a credential issue or something else.
The microsoft docs say, "You can run the remote debugger under a user account that differs from the user account you are using on the Visual Studio computer, but you must add the different user account to the remote debugger's permissions."
In my case, I ran the same account on both machines AND added my account to the debugger's permissions, and it still didn't work. We use Azure AD, and I was using a domain account. My VS computer was on the domain, and the VM was not (even though I could sign in with a domain account). After adding the VM to the domain, I could connect with "Windows Authentication" enabled in the debugger settings.
I am trying to debug a webservice remote on Microsoft Azure. The service is running in a web role.
I have configured remote debugging in the publish settings an can attach the debugger to the web role. Also, when I have selected the correct process, the debug symbols are loaded correctly and breakpoint's tool tips say that the breakpoint is hosted in "WallSHost.exe" which is the remote process.
What I would like to do, is to run a local client software which I am developing and step into the server code from there. When I step into the according service client call (F11), I get the above error message, saying (for the sake of Google in plain text here):
Unable to automatically step into server. Connecting to the server
machine 'xyz.cloudapp.net' failed. The Microsoft Visual Studio Remote
Debugging Monitor (MSVSMON.EXE) does not appear to be running on the
remote computer. This may be because a firewall is preventing
communication to the remote computer.
I have tried to disable the firewall on my (the client) machine with no effect. Has anybody seen that before or can tell me how fix this problem?
A quick checklist
deployed cloud service is a debug build
a debug build is selected from Build Configuration list (in publish wizard)
'Enable Remote Debugger For All Roles' is checked
no changes to code since deployment
I'm trying to set up remote debugging across domains. My Windows 7 workstation running Visual Studio 2010 is on one domain and I'm trying to debug an ASP.NET app running in IIS 7 on a Widows 2003 server box in another domain. I have found many instructions on how to set this up, this being the best, most clearly written one: http://blogs.interknowlogy.com/2011/11/16/remote-debugging-from-visual-studio-2010/
However, I can only seem to connect to the remote debugging monitor on the server if Visual Studio is being run as the local user on my workstation, not as the domain user. This creates a number of challenges, such as loss of source control connectivity. When I try to connect using the domain user I get the following error: "Unable to connect to the Microsoft Visaul Studio Remote Debugging Monitor named 'username#servername'. The specified account does not exist." (I have substituted a generic username#servername for the actual values)
I have found a number of sources suggesting this will work with the domain user running VS2010 but have had no luck. Any idea what I might be missing?
Solved
First, i've read #KyleMit's answer on the same question and done all steps.
But, for across domain debugging also need to edit C:\Windows\System32\drivers\etc\hosts file on local computer.
Just add remote computer's ip address like this:
172.172.172.172 SRV-TEST-ADRESS
Where:
172.172.172.172 - ip address of your remote server
SRV-TEST-ADRESS - Server's name from Visual Studio Remote Debugger
Monitor on remote computer
You can know your server's ip address by ipconfig in cmd
After that, i could attach to proccess on remote computer across domain.
I need to do remote debugging of managed code (.NET) on a server hosted on a different network. Neither the client or server is on a domain so i have to use the public ip of the server.
I'm trying to use Visual Studio -> Attach to process -> default transport with the qualifier john#xx.xx.xx.xx but it's not working.
I get the error message : "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'john#xx.xx.xx.xx'. There is no server by the specified name running on the remote computer"
This error message tells me i can connect just fine but it can't find the msvsmon instance (which is 'john#WEB-001'). So i tried to use the combination of qualifiers such as WEB-001\john#xx.xx.xx.xx and xx.xx.xx.xx\john#WEB-001 but neither are working.
If I choose the transport "Remote (Native only with no authentication)" it connects just fine and I can see the process list on the server but it is pretty much useless because I can't debug managed code.
The administrator 'john' exists on both computer with the same password
Windows 2008 R2 X64 (Server)
Remote debugging component (VS2010) X64 installed
Firewall off
Msvsmon new server named 'john#WEB-001' running as john
Windows 7 X64 (Client)
Visual studio 2010 running as john
Firewall off
Any idea how to fix this, or is this scenario not supported? Thanks
having you tried putting web-001 in your hosts file, and connecting as john#web-001?
Try adding the server name to your hosts file:
192.168.1.100 WEB-001
Replace the IP with your own. Native code debugging is done over plain TCP/IP with no security but native code requires DCOM to enforce security, I don't understand the reason but ....
I know this is an old thread now but.
When the remote debugger is first installed you can set a firewall setting that allows all web traffic or only subnet connections. Run the configuration again to allow all web traffic.
Also, as the Administrator account, not a user in the Administrator group, Shift+r-click on the debugger shortcut to execute as a different user. Enter in the other user account that has the same username and password as the machine you are debugging with, in this case john.
This is the process I have to use.
Windows Server 2008 / IIS 7...
I am trying to setup and CI environment using TeamCity 4. So far so good, VisualSVN Server / Subversion repository is all set, TeamCity is monitoring it, and firing off the build. I can use the TeamCity Webapp via http:localhost:8080 with no problem. My issue is that I can't access the TeamCity webapp remotely from my development machine. I feel like this is problem with the Apache / Tomcat configs, but don't even know where to begin. Anyone have any thoughts?
I installed TeamCity 3.2.x on a Windows 2008 server and didn't run into any problems hitting it remotely, but you may want to check the firewall to see if it's open on port 8080. Windows Firewall > Inbound Rules > sort by port, and see if you have a rule defined for local port of 8080. If not, add it.
IIS Manager might be worth looking into too... (Start > type IIS Manager) And look at the site settings for TeamCity
It's also possible that if IIS is running properly, you'll be able to hit the machine locally on port 80, just to confirm general connectivity.