I have two computers (Window OS) in two different location but in same network. One is very old. I hope the user of that old computer can be very easy to access newer computer.
Ideally, the user turn on the old computer. Then the old computer will send wake on lans message to new computer. The old computer will automatically open the virtual PC in new computer. It will be best if the whole step is automatic. Or it is ok if there can be a shortcut or bat file that can perform all above step.
When the user shut down computer, both computer will be shut down if new computer is not logged in by a window user. Or else, only old computer will be shut down.
I guess that is not such solution? Anyway, I am curious to know.
Separate the steps:
Start remote computer using Wake-on-Lan (tools available)
Start VM on remote computer (tools available, too, but might need a bit of manual scripting)
Log in to VM on remote computer (easy)
Shut down VM on remote computer (done by user)
On remote computer, shut down if no VM running (can be achieved by a simple script).
Step 2 is probably requiring the most manual work, but in general, this shouldn't be all too difficult.
Related
Our team has ~80 Windows development machines, and activities of each developer are logged as text files on the local storage of those machines.
To analyze the logged activities, I want to gather all log files from those machines. Additionally, the log files are updated constantly, so It is desirable to gather files with the command-line from my machine.
I’ve searched and found some solutions, but all of those are not suitable for our situation:
We cannot use PsExec, because tcp/135 and tcp/445 are both closed (countermeasure for WannaCry).
Administrative share is disabled.
telnet service is not up and is banned by security reasons.
WinRM is disabled on those machines by default.
It is difficult to install new software like OpenSSH on those machines (because of the rule of this project)
RDP is the only way to connect those machines. (I have an account on all machines)
How can I copy files from remote Windows machines with command-line through RDP?
Or, at least, is there any way to execute a command on remote Windows machines with command-line through RDP?
I think you can do this, though it is very hacky :)
For a basic setup, which just copies files once, what you would need to do is
Run a script in the remote session when it logs in. I can think of three ways to do this:
Use the "Alternate Shell" RDP file property. This runs a specified program in place of explorer.exe on login; you can use it to run "cmd.exe /c [your script]" for instance.
If that doesn't work (e.g. the remote machine doesn't respect it), you might be able to use a scheduled task that runs the script on login, but perhaps only for a specified user, or maybe the script could check the WinStation type to make sure this is actually an RDP connection before doing anything.
It's also possible to do this by connecting in RemoteApp mode and using the script as your "application", but that only works for Server and Enterprise editions of Windows.
Enable either drive redirection or clipboard redirection on the RDP connection, to give you a way to get data out.
Drive redirection is much simpler to script; you just have the remote script copy files to e.g. "\\tsclient\C\logs".
Clipboard redirection is theoretically possible - you have the remote script copy, then a local script paste - but would probably be a pain to get working in practice. I'm only mentioning it in case drive redirection isn't available for some reason.
You would probably want to script to then log the session off afterward.
You could then launch that from command-line by running "mstsc.exe [your RDP file]". The RDP files could be programmatically generated if needed (given you're working with 80 machines).
If you want a persistent connection you can execute commands over, that's more complicated, but still technically possible. Two ways I can think of:
Use the previous method to run a program on logon, but this time create a custom application that receives commands using a transport that isn't blocked and executes them in the session. I've done this with WCF over HTTP, for instance; it's not secure, of course.
Develop and install a service on the remote machine that opens an RDP virtual channel, and a corresponding RDP client plugin that communicates with it. You can then do whatever you want across the connection. While this solution would be the most likely to work, it's also the most heavyweight and time-consuming to implement so it's probably a last resort.
In order to build an automated deployment pipeline, I need to be able to clone and deploy Windows Server virtual machines, sysprep them, and then perform various customisation tasks on them.
Some steps, such as sysprep, require a reboot, so I currently simply wait for the reboot to happen, and once the machine comes online again I can execute the customisation on it.
The problem with this is that sysprep performs various actions after the reboot, and as far as I can tell, everything on the machine becomes available during the time when "preparing Windows" is still showing on the machine. This means I can use PowerShell Remoting to start changing things, but I don't want to do my customisations which could reboot the machine, while the first-boot stuff is still happening.
How can I remotely detect that a machine is "fully" booted, or at least past any deployment stages so it's in a state ready to log into? Is there some service that only starts when the login is available? Maybe a registry key to indicate that the boot process was completely fully?
This loop does the trick pretty well for me.
while (-not (Test-Path \\machineName\c$)) {
Start-Sleep 1
Write-Host "Waiting..."
}
From what I've experienced, the file system is accessible a couple seconds after the login screen appears, so I'd assume the system is "fully" booted.
make a loop and wait for following registry key to become IMAGE_STATE_COMPLETE
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\State
IMAGE_STATE_COMPLETE represents fully completed sysprep after reboot.
I've got a Windows 7 machine set up on Paralells.
Everything is working fine. Can access internet from IE or other browsers on my Parallels.
However, when trying to debug a web application in Visual Studio 2010 (by pressing F5 for example) then my default browser in OSX launches, which is great, with localhost:4243 (or whatever port Cassini has allocated on my vm)
Naturally, this doesn't find anything...
What do I need to do to either my parallels vm, or the settings on OSX to get debugging working? ie- my mac talking to the vm?
Make sure you are on the same network.
Use IIS.
Like so:
Your Win-machine has a name, let's say it's called "myWin7machine". Change "localhost:4243" to "myWin7machine:4243" in the browser.
If this doesn't work (well... it shouldn't) you might have the firewall on or the network not bridged. Let's start with the bridging.
Time to check some basics - be on the same network
Check your IP address. It's "ipconfig" on the Win machine and "ifconfig" on the mac; both run from the command prompt. The IP address should be something like 10.4.... or 192.168... on both. The important thing is that only the last number is different. (this is technically not correct but works for 99% of the cases) If they are equal (except the last) you are bridged - which means both machines are on the same network. If they differ too much you had running the Win machine's network "inside" the Mac's. Go to the settings for Parallels (in windows: move your mouse to the top to show Parallel's menu and go to Devices->Network and something "(bridged)". Wait until the balloons disappear and check ipconfig again.
Check that you can ping the Win machine from the Mac. Ping functionality might be turned off in the Win machine but probably isn't.
Now we know we are on the same network.
Still doesn't work
Can you do http://myWin7machine:4243 from the mac? Well.. you shouldn't be able to.
Can you do it from the Win machine? You should.
IIRC Cassini doesn't talk to strangers. I.e. it doesn't talk to anything but localhost.
If I am wrong - just open port 4243 in the firewall on the win machine and you should be good to go.
But otherwise...
Time to change web server.
Install IIS on the win machine.
In the Mac: surf to http://myWin7machine and see the IIS7 logo show.
If you don't you have a firewall issue. Open port 80. Try again.
If you have come this far then you can surf from the Mac to the IIS on the Win machine.
Time to set up your VS solution
Open the IIS admin GUI. Create a new Site. Let's say you call it MyTestSite. (you can always rename it later) Point it to your VS solution's web. Typically the same folder as web.config resides in. On the win machine: try surfing to "http://localhost/MyTestSite". Your site should show up. You might get an Apppool error.
Now try http://myWin7machine/MyTestSite on the Mac. It should work.
ROCK!
Time to set up debugging in VS
For debugging in IIS you have to connect to the process. In Win7 it requires elevated privileges so either you restart VS as admin or you try to connect and VS will do it for you.
The menu in VS is Debug->Attach to process and you choose w3wp.exe.
This is how you debug faster anyway - by connecting. Restarting your web for every debugging session is a waste of time.
To make connecting faster - use ctrl-alt-p and the continue with using the keyboard.
To make connecting even faster use a macro.
There is more info in these 4 articles: http://www.selfelected.com/tag/iis/
Set a breakpoint. Refresh your browser and the breakpoint should be hit.
Time to hack some code
Good luck!
I'm using Windows 10, VS 2015, Parallels 11 on iMac with OS X El Capitan (10.11.5). The following are the steps that worked for me:
On Windows side:
Get the IP (run ipconfig command in command window)
Get the host name (run hostname command in command window)
In control panel look for Windows Firewall -> Advanced Settings and add a new inbound rule and a new outbound rule. For both make sure you select Port, Allow Connection, TCP and specific IPs. I added a range of IPs 45000 - 45999 but you can select the range you like.
In Visual Studio:
Look for project properties and under web section change Server settings to look something like this.
Instead of "winmac" you will use the host name found in "Windows Side - Step 2". The port can be any number inside the range you setup for your firewall rules.
On Mac OS side:
Update /etc/hosts file. At the end of the file add the IP and host name that we found on steps 1 and 2 of the "Windows side" section. When you finish this step the file should like something similar to this.
Ready to debug:
Now you can start debugging in your Mac from Visual Studio. Make sure that before start the debugging process you select "Open In Mac" option (instead of Chrome or IE in your debugging options in visual studio).
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.
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