I have two machines in two different domains. On both I have VS 2005 installed. I want remote debug between them. Without authentication it is possible but I want to debug managed code. I don't want to debug directly since it is really crappy machine.
When I try to attach with debugger I get message "The trust relationship between this workstation and primary domain failed." Any idea how to overcome this ? I tried tricks with adding same local username on both machines but with no luck.
EDIT: I have same local users on both machines. I started both VS2005 and Debugging monitor with RunAs using local users. I turned Windows Auditing on debug machine and I see that local user from VS2005 machine is trying to logon. But he fails with error 0xC000018D (ERROR_TRUSTED_RELATIONSHIP_FAILURE)
Gregg Miskely has a blog post on this. You might get it to work if both local accounts have the same user name and password. You might also try dropping your good box from it's domain so that you are going from a workgroup to a domain rather than domain to domain.
I seem to remember that I have sometimes found it useful to use RunAs when you run msvcmon (or whatever it's called this week - the remote debugging stub anyway), to force it to start as the user which you have set up to be the same on both machines.
I would guess that on the machine you're running VS on, you will also need to log in as the local user rather than a domain user (or start VS with RunAs).
I have never understood why this needed to be so hard, given that unmanaged debugging is so much easier, and must expose every security hole that managed debugging could.
The blog post wasn't totally clear that this would work, but I was able to run Visual Studio as my domain account and still debug a process on a machine that was not on a domain.
I have a physical development machine PHYSICAL on a Active Directory domain DOMAIN. I'm logged in and running Visual Studio as DOMAIN\employee.
I have a virtual machine VIRTUAL that is not attached to an Active Directory domain at all. This is the machine running the process I want to debug.
Like the blog post says, create local accounts PHYSICAL\employee (on PHYSICAL) and VIRTUAL\employee (on VIRTUAL). They both must be Administrators and have the same password as DOMAIN\employee.
The remote debugger and the process to debug must be run on VIRTUAL while logged in as VIRTUAL\employee. Then on PHYSICAL while logged in as DOMAIN\employee I can use "Attach to Process..." and connect to VIRTUAL to get a process list.
Related
I have script which uses mircrosoft's UIAutomation to automate an application. The script is inside a VPS running Windows Server 2012. The script works perfectly while I am connected to the VPS via Remote Desktop (RDP).
When I am not connected, the script seems to be stuck on SetFocus for a object... which leads me to believe that the script needs a Display/Screen/Session in order to work... but I am not sure if it is possible to do it while I am not connected to the VPS.
I can see 2 possible solutions here, either modify the script in someway to work in this environment or make the VPS have a virtual desktop while I am not connected (this solution might be more related to Server Fault rather than StackOverflow).
I am very confused, thanks for the help in advance :)
I managed to workaround the issue by actually connecting to the server to itself (to 127.0.0.1) via RDP so that it will always have an active RDP session for the automation script to run.
I am not happy with the results but it works... I cannot give clear instructions on how you would need to modify the settings in Windows to allow RDP connections from self, it was a one big trial and error process, I have to modify some policies in the Group Policy Editor and then some stuff that I don't remember.
There is another downside to this, a Windows server will allow 2 simultaneous connections to it but by using this method we are reserving a slot so only 1 connection at a given time is possible, something to be aware of.
We use many remote desktops in our development environment and there are many servers deployed in multiple environments. It is tedious to remember their IP addresses, usernames, and passwords. I want to write a small utility with buttons on it. When clicked, I want to start those remote desktops, automatically fetching usernames and passwords from some list.
I know there is a command line equivalent for MS Remote Desktop: mstsc.
This question suggests to do this as follows:
cmdkey /generic:TERMSRV/"computername or IP address" /user:"username" /pass:"password"
mstsc /v:"computer name or IP"
I run the first line, and it says credential successfully added. Then when I run the second line it simply runs Remote Desktop Connection for the specified IP address and asks for username and password. I would like it to simply open the remotely connected desktop at specified IP address by automatically applying the credential specified in cmdkey.
What's wrong here? Is it possible using such PowerShell script?
Can I invoke this script through an HTML page (since there are many other resources that I will be laying onto the webpage which will serve as one spot links for we developers, so that we will not be wasting time and effort finding them each time we want them)? Is it possible by registering the application to a URI scheme?
Is there another (standard) way?
The problem in your attempt is the parameter /generic.
According to the official website for cmdkey, /generic
identifies the computer or domain name that this entry will be associated with.
In my example, I will call the computer Computer01.
Do you want the credentials associated with TERMSRV/Computer01 ? (Like your example /generic:TERMSRV/"computername or IP address " said)
No, you want it associated to the normal computername Computer01.
Then you have to remove TERMSRV/.
The working result is:
cmdkey /generic:"computername or IP" /user:"username" /pass:"password"
To your other questions:
See the answer above
I don't know if it's possible with HTML only. I don't think so. But I also implement some PowerShell scripts into ASP.NET. This works.
See answer above.
A lot has changed since 2013. Many system operators already suggested to use ready-made tools which does this. Back in year 2013, Windows store wasn't that great a place (*my opinion). But now it's OK.
There is Microsoft's own Remote Desktop application in the store. The application is universal, that is, it runs on PCs, mobile phones, and holographic devices.
What's good? Microsoft has made the same app available on Android. I have tried for PC and Android. Both work great.
So have a try. I am regular user of these applications now.
I need to debug some C# code on a remote machine running XP Embedded. I did remote debugging on several occasions on different Windows operating systems and all worked well, but I think that the XP Embedded OS is missing something.
I'm popping my brains out in the last couple of days, reading and trying stuff, but nothing seems to work. So if you have been in the same situation and found a solution, please help. Here is what I did up to now:
Successfully established a remote debugging connection to an XP Professional environment, so I know that there's nothing wrong with my remote configuration.
Started the same services on the Embedded environment that are running on the Professional environment.
Configured DCOM permissions, firewall, local users with same name and passwords on both local and remote machines. Gave local users administrator rights.
Started msvsmon.exe both as an application and as a service, under the local user account, wich also has log on as a service rights.
Triple-checked that there is no other firewall between the machines that could drop remote debugging packets.
If I use the No authentication (native only) mode on the Embedded machine, the remote debugging works and I can see the processes. Otherwise, I get an error:
Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named '[NAME]'. The debugger cannot connect to the remote computer. This may
be because the remote computer does not exist or a firewall may
be preventing communication to the remote computer. Please see
Help for assistance.
Thank you for the time you took to read this and any suggestion may help. Thanks!
Can you use WireShark to capture the data going to the remote XP embedded device? If you get a TCP acknowledgement, at least you'll know it's not a firewall problem.
Did you tried to start msvsmon.exe with admistrator rights ? Maybe that is the issue, a post by John Robbins explains it : http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/06/15/vs-remote-debugging-across-workgroups-or-domains.aspx.
I'm adding WMI publishing to a .net framework 3.5 based windows service that is running under the 'network service' account.
According to a document I came across on MSDN, the 'network service' account should by default have WMI publishing permissions. ("By default, the following users and groups are allowed to publish data and events: ... Network Service, ...")
However, when the service calls Instrumentation.Publish(myStatusClassInstance), it throws a DirectoryNotFoundException;
System.IO.DirectoryNotFoundException was unhandled
Message: Could not find a part of the path 'C:\Windows\system32\WBEM\Framework\root\MyWMINamespace\MyService_SN__Version_1.0.3686.26280.cs'.
..so it looks like System.Management.Instrumentation tries to generate code on the fly, and when running under network service it targets a directory where network service has no permissions.
What is the best fix/workaround for this? Can I override the code-gen target dir in app.config or in code? I don't want to have to fiddle around with file system permissions when deploying the service...
Update: I think this is a 'feature' where older FX code clashes with newer security settings in Win7. Internally the WMI managed classes retrieves the WMI installation directory from registry, and uses that as the output path for generated code. Unfortunately a lot of users are not allowed to (or supposed to) write stuff under %SystemRoot%... ...I filed a connect bug (#530392) to see if MSFT can bring any clarity and/or provide a fix or workaround.
Update 2: I'm guessing that for normal user accounts this is not an issue, because UAC virtualization will kick in and store the files elsewhere. However, apparently the 'network service' account is not covered by UAC virtualization..(?)
Update 3: Added 550pt bounty. Simple constraints: .net framework 3.5 based windows service, running as network service, need to be able to publish data through WMI using System.Management.Instrumentation on Win7 and Win2008[RTM & R2] with default permissions/security settings and without resorting to modifying framework internal/private members using reflection. 'Out-of-the-box' but clean solutions welcome. Will open a second related bounty-Q as a placeholder for another 550pt if SO allows.
Bounty update: I intend to double the bounty for this Q through a second hand-in-hand question that will serve as a bounty placeholder:
https://stackoverflow.com/questions/2208341/bounty-placeholder ( <-- Apparently this was not allowed, so the bounty placeholder question got closed by the SO etiquette police.)
Update 4: This gets better and better. I noticed that installutil was writing the missing files to c:\windows\syswow64...etc..., so I realized that I was using the 32-bit version of installutil to install the service, but the service was running as a 64-bit process. The obvious side effect was that code generated when installutil was running ended up under syswow64 (the 32-bit system directory), while the service was looking for it under the 64-bit system directory (system32). (<-- off topic, but I really like how MSFT managed to switch around the names there... :) ).
So I tried installing the service with the 64-bit version of installutil. That failed miserably with permission errors in the %sysroot%\wbem\framework...etc... path. Next I recompiled the service as x86 and registered it again using the 32-bit version of installutil. That resulted in an entirely new exception:
System.Exception: The code generated for the instrumented assembly failed to compile.
at System.Management.Instrumentation.InstrumentedAssembly..ctor(Assembly assembly, SchemaNaming naming)
at System.Management.Instrumentation.Instrumentation.Initialize(Assembly assembly)
at System.Management.Instrumentation.Instrumentation.GetInstrumentedAssembly(Assembly assembly)
at System.Management.Instrumentation.Instrumentation.GetPublishFunction(Type type)
at System.Management.Instrumentation.Instrumentation.Publish(Object instanceData)
at SomeService.InstanceClass.PublishApp(String name) in e:\work\clientname\SomeService\SomeService\WMIProvider.cs:line 44
at SomeService.SomeServiceService..ctor() in e:\work\clientname\SomeService\SomeService\SomeServiceService.cs:line 26
at SomeService.Program.Main() in e:\work\clientname\SomeService\SomeService\Program.cs:line 17
...getting closer...
I believe the problem is not with publishing data, but with registering that type in WMI for the first time.
If you examine the System.Management.Instrumentation code in reflector, or some other disassembler, you'll see that wen the assembly that is about to publish hasn't been registered, then the code will try to register the assembly and save the assembly info in a specially named sub directory under the WBEM installation folder.
I suspect that if you run code to publish the WMI data as an administrator first, it would register the assembly and then the Network Service account would have the permissions to do the normal publishing.
Have you inspected your assembly with the installutil? That should give you a log of the installation issues. (But since you can't run it as the Network Service account, it might not show the problem you're having.)
Also, are you sure this service must be run under the Network Service account?
Because of the vulnerability risk in running Windows services in privileged accounts, Microsoft has made these special service accounts with some limitations, which were strengthened in Vista and Win7. Since Vista, Microsoft has limited the number of services running under this account in favor of less-privileged ones (see this article). The Network Service account (aka "NT AUTHORITY\NETWORK SERVICE") can access the network (acting as the local machine account PCNAME$), but it has reduced rights on the local machine (unlike the Local System account).
Have you checked the WMI security permissions for the branch your assembly is using? Run wmimgmt.msc and dig in... When I did a quick check of some random branches, I could see that the Network Service account did not have write rights.
Lastly, I would suggest using Sysinternals' ProcMon, which would allow you to filter to just that process and see if there are any Access Denied errors in file or registry settings. This tool has solved many problems for me over the years.
Not sure if you raised it or someone else but please have a look:
http://connect.microsoft.com/VisualStudio/feedback/details/530392/wmi-publishing-fails-on-permission-error-please-provide-a-way-to-override-codepath-in-system-management-instrumentation-schemanaming-in-app-config-web-config
This may help you to understand the root cause of the issue better
At work, I running Vista Business on a lavishly new PC, which runs great excepting two issues. In order of annoyance, but not importance:
When I reboot the machine, the Windows Splash is presented asking me to Press Ctrl + ALT + DELETE so I can logon. It takes three to five minutes and seceral key presses for me to be prompted to select my user account. After which, everything works like a charm.
As part of my duties with the firm, I am responsible for emergency work on a rotating basis and deploying patches during off-business hours. I have been given an older laptop with XPSP2 (downloading 3 for kicks right now) which I use for browsing with the intention of RDP to my desktop in the offices. If I am connected at the domain through conventional means, I am able to RDP. However, if I am using an existing broadbad connection with VPN, I am not able to get access. I am able to access other servers, desktops running a variety of OS'es including Vista.
So umm any ideas guys?
as for 2 - this happens with some proprietary VPN software (i.e. Cisco). My solution was to perform my work duties in a Virtual PC (which doesn't need its normal LAN abilities) and do my other network/internet tasks in the physical machine.
I have a Vista at work and uses my home PC to rdc in for support work. I do not experience your problem 1 so I cannot offer any advice. For your second problem have you tried the IP address instead of the machine name? We have situations where sometimes the dns resolution in the office network is not accurate.
Do you have remote access enabled, either on the machine, via group policy?
If not, you might have to go into the Control Panel\System and Maintenance\System and choose Remote Settings (from the menu on the left).
That will show you the options for Remote Deskop, including Don't allow connections, Allow connections from any version of Remote Desktop, and Allow connections from computers running Remote Desktop with Network Level Authentication (which might be the hang up you are experiencing over the VPN).
Good Luck.
I have to chalk this up to "something wierd with my laptop" as I was able to download RoyalTS and connect to the machine just fine. I had Remote connections permitted, firewall disabled, McAffee gone and others could access the machine.
The advice garnered above is excellent and useful for your typical rdp connections