When attempting to forcely uninstall a software from the server, I switched off these two components from MSCONFIG.EXE:
MSConfig Screenshot
After rebooting the server, it doesn't respond anymore to RDP connections.
The Google Cloud Panel shows that the server is running, has an internal and external IP Address, but I cannot access it by any means. I already rebooted, stopped and started it many times.
This is the output for SERIAL PORT #1:
SeaBIOS (version 1.8.2-20181112_143635-google)
Total RAM Size = 0x00000000f0000000 = 3840 MiB
CPUs found: 1 Max CPUs supported: 1
found virtio-scsi at 0:3
virtio-scsi vendor='Google' product='PersistentDisk' rev='1' type=0 removable=0
virtio-scsi blksize=512 sectors=104857600 = 51200 MiB
drive 0x000f2a30: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=104857600
Booting from Hard Disk 0...
I am able to connect to SERIAL PORT #2, to try a deeper troubleshooting, but the first message after connection is this:
Computer is booting, SAC started and initialized
And when trying to open CMD command, this is the response:
SAC>cmd
Error: Unable to launch a Command Prompt. The service responsible for launching
Command Prompt channels has not yet registered. This may be because the
service is not yet started, is disabled by the administrator, is
malfunctioning or is unresponsive.
Does anyone know how to recover this server?
Thanks!
You unselected "Load system services". This means that nothing is loaded in Windows. The services that are required so that you can access the system remotely are not running.
You have two options:
Mount the disk on another Windows system, mount the registry and change the settings for these two items (I don't rember but this information is on the Internet). Then unmount the registry and create another VM with the disk.
Create a new instance and attach this disk as the second disk drive. Copy all the data from the second drive to the first drive. You will loose system settings, applications, etc but at least you can save your data.
Related
I am running a Windows Server VM on GCP.
When logging in via Remote Desktop, I am starting certain applications which should actively run for a couple of hours.
But when closing my Remote Desktop Connection, all applications stop working.
How can I prevent this from happening?
In order to keep the session ongoing, you'll have to configure the RD Session Host time limits.
Open the group policy editor with: Windows+R, then type gpedit.msc, confirm with Enter.
Then in the management console, navigate to:
Computer Configuration
Administrative Templates
Windows Components
Remote Desktop Services
Remote Desktop Session Host
Session Time Limits
There one can adjust the settings:
Set time limit for disconnected sessions
Terminate session when time limits are reached
I'm new at GCP and I'm trying to keep my process running on Jupyter Notebook after shutting down my local PC. Does anyone know how can I do it? Nowaday I open a terminal on my VM run jupter notebook and then after start the process on jupyter I'd like to turn my machine off.
I keep following the process on my cellphone and shutdown on there. Does anyone know how to turn this off automatically when it stops?
Sorry to make two questions at once, but I think that one is related with another. If it does not I can edit and make another one.
This is a technical limitation of Jupyter Notebooks unfortunately. The browser window contains the code which updates the notebook itself, so if you close the browser window then there is not process running to update the notebook.
However, there is one workaround which you may find useful.
There is a library called Fairing that you can use with GCP's new AI Platform Notebooks which allows you to pack up your notebook and run it remotely, and that library will save the results of that execution in a GCP Storage bucket. No active internet connection required (once you kick of the notebook run).
You can learn how to use it by creating a new GCP AI Platform Notebook and looking at the tutorials folder inside it. You can also find additional tutorials for Fairing here
Typically to keep your remote sessions up in the event of network connectivity loss (which also covers shutting down the local computer) you'd use a terminal multiplexer application. From Known issues:
Intermittent disconnects: At this time, we do not offer a specific SLA for connection lifetimes. Use terminal multiplexers like tmux
or screen if you plan to keep the terminal window open for an
extended period of time.
But these multiplexers are terminal/text-mode apps, so you'd have to launch the notebook with the --no-browser and then connect your local browser to its port.
You can find a recipe based on tmux and a local browser connection to the notebook using an SSH tunnel at Using Jupyter notebooks securely on remote linux machines.
As for shutting down the session - you'd just have to instruct the multiplexer application to end the session (or terminate the multiplexer app itself) - which you could do automatically via a wrapper script first invoking your process and immediately after the process ends invoking the commands to shutdown the session.
I uploaded a hyper-v VHD file to storage. I then created a Windows VM from disk and specified that it contains the operating system. Azure says the machine is running and the remote desktop and powershell endpoints are configured. However, When I click connect I get the standard rdp error.
I have resized the VM and restarted the VM a few times to no avail.
Clicking Reset Remote Connection has failed in the Azure Preview Portal. This button is now disabled.
When I run (Get-AzureVM -ServiceName XXXXXX -Name XXXXXX).GuestAgentStatus it returns:
ProtocolVersion : 1.0
TimestampUtc : 10/13/2015 2:02:29 PM
GuestAgentVersion : Unknown
Status : NotReady
Code :
Message :
FormattedMessage : Microsoft.WindowsAzure.Commands.ServiceManagement.Model.GuestAgentFormattedMessage
ExtensionData :
I worked with Microsoft Support in resolving this issue. For those who have posted similar unanswered questions you need to edit the registry of the VM to disable the firewall and change the RDP security settings of the VM.
Delete your VM but keeping the attached disks.
Create a temporary VM from the gallery
Attach the original vhd as a disk to the temporary VM.
Bring the disk online, if it is not already.
Use Regedit to load the System hive from the attached disk under the HKEY_LOCAL_MACHINE key.
Turn off the firewall: Check your OS Registry keys. For a windows 7 machine: Open the following key for each of the ControlSetsXXX
HKEY_LOCAL_MACHINE\YOURLOADEDHIVENAME\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy
Set EnableFirewall = 0 in the DomainProfile, PublicProfile and StandardProfile subkeys
Modify the RDP security settings: Open the following key for each of the ControlSetsXXX
HKEY_LOCAL_MACHINE\YOURLOADEDHIVENAME\ControlSet001\Control\Terminal Server\WinStations\RDP-Tcp
Set the values: fAllowSecProtocolNegotiation, SecurityLayer and UserAuthentication to 0
Unload the Hive
Take the disk offline
Detach the disk from the temporary VM
Shutdown the temporary VM and delete it
Create your VM as your did previously
Connect to your VM and rdp into it. Set the appropriate Firewall rules for RDP and turn the firewall back on.
Original information taken from:
http://social.technet.microsoft.com/wiki/contents/articles/18710.troubleshoot-azure-vm-by-attaching-os-disk-to-another-azure-vm.aspx
and
http://www.technlg.net/windows/disable-enable-firewall-registry-key/
We occasionaly have a problem where we attempt to start the Jrun service and it fails with the following two errors:
error JRun Naming Service unable to start on port 2902
java.net.BindException: Port in use by another service or process: 2902
info No JDBC data sources have been configured for this server (see jrun-resources.xml)
error java.net.BindException: Port in use by another service or process: 8300
We then have to reboot the machine and Jrun comes up with no problem. This is very intermittent - happens perhaps one out of every 10 times we restart Jrun services.
I saw another reference on StackOverflow that if Windows Services take longer than 30 seconds to restart Windows shuts down the startup proccess. Perhaps that is the issue here? The logs indeed indicate that these errors are thrown about 37+ seconds after the restart command is issued.
We are on a 64bit platform on WinServer 2008.
Thanks!
We've been experiencing a similar problem on some of our servers. Unfortunately, netstat never indicated any sort of actual port conflict for us. My suspicion is that it's related to our recent deployment of a ColdFusion "cumulative hotfix" to our servers. We use the multi-server edition of CF 8.0.1 enterprise with a large number of instances on each machine -- each with its own JVM and its own distinct set of ports. Each CF instance is attached to its own IIS website and runs as its own Windows Service.
Within the past few weeks, we started getting similar "port in use" exceptions on startup, on our 32-bit machines as well as our 64-bit machines, all of which are running Windows Server 2003. I found several possible culprits and tried the following:
In jrun-jms.xml for each CF instance, there's an entry for the RMI transport layer that reads <port>0</port> -- which, according to the JRun documentation, means "choose a random port." I made that non-random and distinct per instance (in the 2600-2650 range) and restarted each instance. Things improved temporarily, perhaps coincidentally.
In the same file, under the entry for the TCPIP transport later, every instance defaulted to <port>2522</port> -- so I changed those to distinct ports per instance in the 2500-2550 range and restarted each instance. That didn't seem to help at all.
I tried researching whether ports in the 2500-3000 range might be used for any other purpose, and I couldn't find anything obvious, and besides, netstat wasn't telling me that any of my choices were in use.
I found something online about Windows designating ports from 1024 to 5000 as the "dynamic port" range, so I added 10000 to the port numbers I had set in jrun-jms.xml and restarted each instance again. Still didn't help.
I tried changing the port in jndi.properties, also by adding 10000 to the port numbers. Unfortunately this meant wiping out all my wsconfig connections to IIS and creating them again from scratch. I had to edit wsconfig_jvm.config as well, adding -DWSConfig.PortScanStartPort=12900 to java.args, so it could detect my CF instances. (By default it only scans ports 2900-3000. See bpurcell.org for details. It's an old post but still relevant.) So far so good!
My best guess is that Adobe (or MS Windows) changed the way some of its code grabs "random" ports. But all I know for sure so far is that the steps outlined above appear to have fixed the problem.
Have you verified that the services are in fact stopping? Task manager should show no instances of jrun.exe. You can also check to see what is bound to that port by opening a command window and running
netstat -a -b
This will list all your open ports, plus what program is using them. You can also use
netstat -a -o
Which does the same thing as the above, but will list the process id instead of the program name. You can then cross-reference those with task manager. You'll need to enable showing the PIDs in task manager by going to View->Select Columns and making sure PID is checked. My guess would be that the jrun processes are not shutting down in a timely fashion.
Two RAID volumes, VMware kernel/console running on a RAID1, vmdks live on a RAID5. Entering a login at the console just results in SCSI errors, no password prompt. Praise be, the VMs are actually still running. We're thinking, though, that upon reboot the kernel may not start again and the VMs will be down.
We have database and disk backups of the VMs, but not backups of the vmdks themselves.
What are my options?
Our current best idea is
Use VMware Converter to create live vmdks from the running VMs, as if it was a P2V migration.
Reboot host server and run RAID diagnostics, figure out what in the "h" happened
Attempt to start ESX again, possibly after rebuilding its RAID volume
Possibly have to re-install ESX on its volume and re-attach VMs
If that doesn't work, attach the "live" vmdks created in step 1 to a different VM host.
It was the backplane. Both drives of the RAID1 and one drive of the RAID5 were inaccessible. Incredibly, the VMware hypervisor continued to run for three days from memory with no access to its host disk, keeping the VMs it managed alive.
At step 3 above we diagnosed the hardware problem and replaced the RAID controller, cables, and backplane. After restart, we re-initialized the RAID by instructing the controller to query the drives for their configurations. Both were degraded and both were repaired successfully.
At step 4, it was not necessary to reinstall ESX; although, at bootup, it did not want to register the VMs. We had to dig up some buried management stuff to instruct the kernel to resignature the VMs. (Search VM docs for "resignature.")
I believe that our fallback plan would have worked, the VMware Converter images of the VMs that were running "orphaned" were tested and ran fine with no data loss. I highly recommend performing a VMware Converter imaging of any VM that gets into this state, after shutting down as many services as possible and getting the VM into as read-only a state as possible. Loading a vmdk either elsewhere or on the original host as a repair is usually going to be WAY faster than rebuilding a server from the ground up with backups.