I wanted to know if we have mechnisms for hard booting a machine remotely. I know that we access a machine remotely, we can reboot it so that it restarts and remains logged off. But what I need is a option to shutdown the machine (i.e. power off) and boot it back up (power up) remotely whenever I need.
Does there exist any tool, hardware+software setup for the same?
I believe this is a permission defined by the local security authority. You probably just need to assign the privilege for remote shutdown.
Have a look here: http://blogs.msdn.com/b/aaron_margosis/archive/2006/01/27/518214.aspx
Related
I want to Terminate a Azure Virtual machine and all of it's belongings.
What i have done --
I have stopped the Virtual machine
It seems the by stopping Virtual Machine all of it's belongings are also stopped.
Now my question is --
Since i don't need this Virtual Machine ever,
how can i remove everything which belongs to a Azure Subscription !
Any one knows any solution !
Go to the cloud service which holds the vm. Click on delete button. You will get an option to delete cloud service and its deployment. Just do that.
If you are using azure resource manager deployment model and have logically grouped all the resources for that virtual machine under that group. Deleting the resource group itself will remove everything related to that VM.
Box was corrupt and was cleaned up and operational. Now, SQL Server will not connect to my db. I checked services and found that mssqlserver, SQL Server agents won't start. Gives error
Cannot connect to local server
They are set to automatically start, but manually starting gives the same error.
I cleaned his box with this recipe that I use successfully on dozens of computers. All other software is running fine. His box also had a failing disk so I xxcloned (XXClone.com) his disk to a fresh new disk. I believe the cleaning is an unrelated issue, but whatever it takes to fix it we are happy to try. I know many people with this SQL Server issue, and over the years have fixed it a few ways, but I am tight on time, so I suggested he get help here.
THOROUGH BADDY CLEAN. Clean a Windows Machine without Formatting it or losing Data
STEP 1
If Ransomware or some baddy is taking over our MBR or Partition so you cannot escape it, and cannot run safe mode, the ICE Ransomware being one of many examples.....
http://www.bleepingcomputer.com/virus-removal/remove-ice-cyber-crime-center-ransomware
use a empty USB stick and HitManPro (the free version will remove)
http://www.surfright.nl/en/hitmanpro/
STEP 2
Reboot in Safe mode with networking by rebooting and holding down F8 key. None of this will permanently fix your computer unless you are in SAFE MODE w/ NETWORKING
Download RKill and run it
Download ComboFix from BleepingComputer.org and run it
Download SmitFraudFix and run it
Download AntiMalwareBytes to catch everything those did not
I can clean any machine no matter how badly infected with these tools in safe mode. Will keep recurring if attempted in Normal Mode. Safe mode is the key.
I have Starcounter installed on my laptop (i7 mobile). Checking the logfile I found that I had several messages like this:
Memory manager unable to acquire the SE_MANAGE_VOLUME_NAME privilege. Applying slow backup routine
Why does this happen? If this affects the performance is there some way I can improve the installation to avoid this problem, or is this something that will only occur outside a server installation?
Memory manager unable to acquire the SE_MANAGE_VOLUME_NAME privilege. Applying slow backup routine
This is a warning message. It means that the backup will slow. It happens if the code host sccode.exe is run in not elevated mode (without Administrative privilege), which is normal case for Personal server and development environment.
This message will show performance problem in the case of running System server, i.e., in production.
The message should not appear if sccode.exe process runs in elevated mode. Note, that in this case all Starcounter processes and Visual Studio (if used) should be run in elevated mode.
Vista just finished one of its many updates. After restarting my computer I try connecting to SqlServer2008 instance with Sql Server Management Studio and I get this error:
Error connecting to '...\MSSQLSERVER2008'.
Additional information:
Login failed for user '...'. Reason: Server is in script upgrade mode. Only administrator can connect at this time. (Microsoft SQL Server, Error: 18401).
Pressing help gets me to an internet page saying there's no additional information.
Thx Vista & Updates. Anyone an idea because on the internet I can't find anything about this issue.
It appears This Guy was having the same problems as you and his only suggestion was to wait a few minutes before trying to log in again.
I have yet to see any type of Microsoft documentation about this, nor have I seen any forum posts which came to any sort of resolution concerning the same problem.
Check your event viewer. I had the same problem and found that (in my case) it was looking for a directory that didn't exist to perform an upgrade script. NO hint that there was any sort of problem in the dialog, but the event viewer showed clearly what the problem was.
jim
I had the same problem. Waiting until update was done did not help. Solution was, (after checking Windows eventlog) to set the folder rights. SQL-Express had no rights on the database folder, why ever. Something has mixed up the rights during the upgrade from WinXP to Win 7. That was it.
Adding a comment to this page since this is the top Google result for "script upgrade mode". It seems that a number of things can cause a SQL Server DB to go into this mode. In our shop we've run into these two cases in the past months:
Log shipping - Can't recall at what point of the process exactly the DB went into this mode, iirc it was when bringing it back up. The solution was just to wait it out.
Hard drive full - The DB went into this mode when it ran out of space. We're currently clearing up the drive, will come back with an update if waking it up turns out to be challenging.
Update: After freeing up disk space, it was a simple matter of setting the DB "Offline" and then "Online" to bring it back up.
We had the same issue, but needed to know what was going on in the background.
The db's were put into recovery mode, hence they had to recover. To assist we went to the SQL Server error log located where the system files (normally master, model, msdb...) are located, but under the log folder. In the ERRORLOG, we did a find on the word recovery and could watch the db's percentage recovered. Everything recovered normally, but it was much longer than expected.
The Reason for this is that the system reboot happens with important\necesssary softwares loaded and does all other operation later so that the booting happens faster.
Here in your case, the sql booting is happening as the start of SQL is not needed for system to start. I hope you are aware of DAC account(Dedicated Administrator Connection, Link) who has seperate connectivity and has ability to resolve issues even the whole SQL server is not responing. The SQL server is asking you either to wait or open the SQL with DAC account and stop the SQL update.
Solutions:
1) Wait until backround update completes
2) Open SQL using DAC account and kill all running processes
So our web server apps need to connect to the database, and some other apps have startup scripts that execute at boot time.
What's the best way to store the name/password for these applications, in terms of
security, e.g. perhaps we don't want sysadmins to know the database password
maintainability, e.g. making the configuration easy to change when the password changes, etc.
both windows and linux solutions appreciated!
The best way to secure your password is to stop using one. Use a trusted connection:
How To: Connect to SQL Server Using Windows Authentication in ASP.NET 2.0.
Then you have nothing to hide - publish your web.config and source to the world, they still can't hit your database.
If that won't work for you, use the built in configuration encryption system in ASP.NET.
PostgreSQL offers a nice solution for this kind of situation in their documentation. Essentially, you use ssh to bridge a port on your machine to the PostgreSQL server port on the remote machine. This has three stages of authentication:
Restrict access to the local port, such as only letting a particular user connect to it.
Set up password-less connection to the PostgreSQL host with ssh as a particular user.
Allow the user ssh connects as to have local access to PostgreSQL without a password.
This reduces the security to whether your user accounts are secured and your ssh configuration is sound, and you have no need of a password stored anywhere.
Edit: I should add that this will work with any database that listens to a TCP/IP port. It just happens to be described in PostgreSQL. And you will want iptables (or the equivalent off Linux) to do the port restrictions. See this.
I agree with lomaxx: if somebody is already on the server or has wide ranging access to it (like a sysadmin), the game is pretty much over. So the idea would be to use a server you trust that it is secure to the degree you want it to be. Specifically:
You need to trust the sysadmins
You need to trust anybody else who is running code on the same server (this is why shared hosting is a big no-no for me)
Beyond that, environment variables seem to be a popular choice for storing these types of credentials, because this means that access to the source only (for example by compromising the dev box) doesn't reveal it directly and also it can be nicely localized for each server (dev, test, etc).
plain text? If they're on your server, I would hope the server is secure enough not to allow unauthorised access. If people can access your config files on the server, something has gone wrong much earlier.
clarification: in terms of security, maintainability (e.g. if the login needs to change, can I find it later, etc)
#lomax: perhaps I might not want everyone with access to the physical server (e.g. sysadmins) to see the password.
Thanks!
In most cases, I believe it is sufficient to obfuscate the password in a plain text file (eg. with base64). You cannot completely protect a stored password against a determined sysadmin with root access, so there's not really any need to try. Simple obfuscation, however, protects against accidentally revealing the password to a shoulder surfer.
A more complex alternative is to set up a dedicated secure password server that either:
provides a password decryption service
actually stores the passwords for use by other less secure servers
Depending on the network protocols used, this may not protect against a rogue sysadmin with tcpdump. And it probably won't protect against a determined sysadmin with a debugger, either. At that point, it might be time to look at something like Kerberos tickets.
You can bake a symmetric encryption key into your binary, and have that binary read an encrypted username/password from a file on disk when it starts up.
However, this is not really much more than obfuscation, since your code is likely to be stored in some source repository somewhere.
I would suggest that you would be better served to control access to your servers both physically and over the network using a firewall and a private network bubble, and store the passwords in the clear (or base-64 encoded) on disk with permissions locked down to the run user for your web app.
You can also lock down the database server to only accept connections from your web app machines by IP.
Ultimately, your problem is that the key (your DB username/password pair) needs to be available for programmatic, unattended use by your web apps.