A fresh Windows XP SP3 install does not allow remote WMI access like Windows XP SP2 does.
If I follow the steps in the "How to troubleshoot WMI-related issues in Windows XP SP2" document at http://support.microsoft.com/kb/875605 I'm unable to get SP3 to respond to a remote WMI request.
Every request, even to the built-in Administrator account, a new account in the Administrators group, or even a new account not in the Administrators group but given access to remote DCOM & the WMI namespace as described in the Microsoft document all return error code 0x80070005, Access is denied.
To verify I didn't have a goofy system configuration, I installed a fresh Windows XP SP3 image (using the .ISO image from MSDN) and performed no configuration changes save enabling RemoteAdmin through the Firewall. The Access is denied behavior was seen in this scenario as well.
What changed in Windows XP SP3 to remote DCOM / WMI access and how best to enable it?
It turns out the issue wasn't specific to SP3, but rather the lack of these systems being in a domain.
If XP isn't in a domain then the "Use Simple File Sharing" option, found in the Folder Options control panel applet, works it magic. If this option is enabled (the default) all file sharing connections are done with the guest user credential, but this also is applied to incoming DCOM connections as well.
Disabling this option allows DCOM connections to be verified as expected.
Supposedly SP3 does not check 'Enable Distributed COM on this computer'. Get into Component Services (dcomcnfg.exe) Component Services, Computers. Right click 'My Computer' and go to properties. 'Default Properties' is the tab you want. I have also heard that changing the DTC Logon account to NT AUTHORITY\NetwerkService (note the e instead of an o) will work. You can find this under the MSDTC tab, Security Configuration following the same path to My Computer.
We solved something very similar by using these tricks. Hope this helps.
I'm not sure if RemoteAdmin is the one you need to turn off or not in the firewall.
One suggestion would be to turn off the firewall completely first and try that. If it works, then you know it is the firewall. If this is the case, then I would try adding port tcp 135 directly and try again.
You may also try using telnet [ip address of XP_SP3 machine] 135 and see if you can establish the connection.
Hope this helps.
Related
I have a puzzling situation with the Inno Setup FileExists function.
Here's the situation. I have three networked computers with like WORKGROUP names.
1) Windows 7 32-bit
2) Windows 7 64-bit
3) Window XP Service Pack 3
1) and 3) have been setup as servers with read-write shares, ex. ShareExe and ShareData
The problematic Inno Setup creates shortcuts to the executable in the ShareExe folder. It asks the user for the ComputerName of the server and then uses FileExists to verify correct input.
Running this setup on the XP (3) machine and specifying 1)'s computername works just fine, however when running the setup on the Win7 64-bit PC and specifying the same ComputerName as with XP, causes the FileExtsts test to fail.
Strangely, I can go to Network Places and open the ShareExe folder and successfully run the executable. My question is, "why does Inno FileExists fail only on the Win 7 64-bit machine?" I cannot find anything in the reference materials that suggest any version differences with FileExists. (I also tried FileSearch with the same results).
TIA
In Windows 7 (and Vista) with UAC enabled, by default network credentials and drive mappings are not shared between admin and non-admin contexts, even for the same user.
By default, Inno elevates to admin permissions (via PrivilegesRequired=admin), since most installations must (and should) be performed per-machine by an admin user. However this means that any credentials prompted for or saved by Explorer when browsing for the desktop are not available to it.
When files are accessed directly by APIs (as with FileExists), Windows will typically try to silently connect to the server using the same username/password as was used to log into the PC; if this fails then it just reports an error since it has no way to prompt for alternate credentials at that point. So if you can ensure that the login details on both PCs are the same, then it should work. (You usually get this for free on computers connected to a domain, but not a workgroup.)
If that isn't possible, then something else you could try would be to force the access via a shell dialog -- if the FileExists fails, then use GetOpenFileName to prompt the user to find a specific file in that folder, using the same initial path. I haven't tested this, but I think this should result in Windows displaying a credential prompt and then you should be ok after that.
(If this is for an internal app, then another option is to disable the separation of credentials [via a security policy setting] or UAC entirely, though the latter isn't really a good idea. Of course this isn't tolerable for a general-release app, and it's cleaner if you solve it one of the other ways anyway.)
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.
My organisation produces a suite of Windows applications that make use of networking, and so when users run our software for the first time, the Windows Firewall (if it is running) brings up a pop-up, informing the user that our app(s) are trying to use the network, prompting the user to allow or deny access.
This occurs with plenty of other apps (Spotify, to give one example), but ee'd like to prevent these popups from happening, as they can be a bit problematic for our users. Some Applications (MSN Messenger, GoogeTalk) operate without ever causing the Firewall to alert the user, and we'd like to do the same.
We've successfully done this on Windows XP by having our installer write appropriate registry keys at:
HKLM\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List
However, this does not have the same effect on Windows 7 - the Firewall popups still take place.
Any ideas how we can do this? (Our installers and software are all digitally signed.)
Thanks
Tom Davies
You can add exceptions to Windows Firewall by shelling out to netsh, a utility built into Windows, but the utility works differently on Windows XP and Windows 7. Here are the commands I used:
Windows XP:
add:
netsh firewall add allowedprogram mode=ENABLE profile=ALL name=[exception name] program=[program path]
remove:
netsh firewall delete allowedprogram profile=ALL program=[program path]
Windows 7:
add:
netsh advfirewall firewall add rule action=allow profile=any protocol=any enable=yes direction=[in|out] name=[exception name] program=[program path]
remove:
advfirewall firewall delete rule profile=any name=[exception name]
I actually advise against making this an installer issue for several reasons:
There are multiple software firewalls
out there; you can't code and test
for all of them.
Some (such as the built-in windows
firewall ) have API's that won't
allow you to configure port
exceptions when the FW is disabled.
If the user later enables the FW you
are hosed again.
There could be external firewalls
that still get you.
Instead I prefer to make this a documentation effort so that users and administrators are fully aware of the networking requirements. I once had to goole Apple's website to figure out what ports iTunes needed and I swear to God they made it really hard to find as they tried to soften everything up for consumers.
However, if you want to give it a best faith effort in the install, WiX has a Custom Action extension for interacting with the firewall rather then writing your own Custom Action. Even if you are using another tool such as InstallShield, you can wrap this behavior up in a WiX merge module and then consume it with your primary tool of choice.
You can read about it here at:
Joy Of Setup Blog
and
WiX Documentation
In your installer (i.e. as elevated admin), you need to write code to access the Windows Firewall APIs and add your app as an exception
Is there any way to programmatically add an .exe file to the exception list for the Windows Vista firewall to allow it to run normally? I'm using VC++.
Yes - if you take a look at the WindowsFirewallAddApp method here, it should give you some ideas how to do it.
I don't know for certain about the Vista firewall, but I would defeinitely excpect that it is a violation of the security of any computer to allow programmatic access to firewall exception lists. I would be very surprised if Windows allowed arbitrary code to fiddle with the Firewall in this way.
The user sitting in front of the computer, or a network administrator setting network wide security policies would be the only two who should be able to do this. Notice that they are both actual people doing the process interactively.
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