Recently we have encountered a question of selecting a reliable and fast DNS service providers. Why? The main reason was that 1and1 – the registrar for some of our sites has the most terrible domain control panel ever that does not allow configuring TXT records that we need for SPF. See the comparison below.
Employee monitoring software has become commonplace. Many apps take monitor screenshots, capture keystrokes and mouse movements, monitor active applications and visited sites and, in extreme cases, can even take pictures using webcam. It seems to be fair to track what your employees do when they are being paid for their time. After all, if they exchange their time for money, it seems fair for the employer to know what they are paying for. So, why does it still feel morally inappropriate in some cases? The question is far from being just theoretical. If a wrong decision is made, a company may suffer from lawsuits, experience a backlash and overall productivity drop (opposite from what was intended) from their employees or suffer damage to the company’s image. Let’s review in more detail what employee monitoring practices can be considered valid and what should be avoided.
While working on a network share (Windows Home Server) from a Win7 notebook I’ve accidentally pressed Delete and OK on the wrong (and important!) folder. And then spent several hours trying to restore. Below is the summary of what I have found.
Amazon S3 is a great and cheap place to keep your SQL Server database backups.
SQLBackupAndFTP starting from the Standard version now allows you to backup SQL Server databases to Amazon S3 directly.
To set up the backups you need to have your Access Key and Secret Key that you can find under “Security Credentials” in Amazon Web Services: https://aws-portal.amazon.com/gp/aws/securityCredentials#access_credentials
Google Drive starts you off with 5GB for free. Seems like a great place to keep you SQL Server database backups.
SQLBackupAndFTP starting from the Standard version now allows you to backup SQL Server databases to Google Drive directly. On the main form just select Google Drive as your backup destination, authorize the program with Google – and you are done!
SkyDrive from Microsoft gives you 25GB of cloud space for free. Seems like a great place to keep you SQL Server database backups.
Here’s how to backup SQL Server databases to SkyDrive using SQLBackupAndFTP:
- When you install SkyDrive, it creates a special folder. Everything that you put into this folder will be synced to the SkyDrive servers in the cloud.
- Open SQLBackupAndFTP, select databases to backup, check “Store backups in a local/network folder” and set the folder to be that SkyDrive folder.
Note that there’s a big drawback – SkyDrive will sync only when you are logged in.
Dropbox allows you to store 2GB for free – this should be enough space to store SQL Server backups for the majority of small clients. Free version of SQLBackupAndFTP now allows you to backup SQL Server databases to Dropbox directly.
- Select the databases you want to backup
- Click “Add backup Destination” and select Dropbox
- Click Authorize button to allow SQLBackupAndFTP to save to your Dropbox account
- Click Test or Run Now to verify that backups work correctly
- The backups will be stored in Apps\mySQLBackupAndFTP folder in your Dropbox account
- Now schedule your SQL backups and sleep well
When you Remote Desktop to a Windows XP Professional computer, you always connect to the console (main/default) session. This is the default for Remote Desktop to Windows XP Professional. When you remote desktop to a Windows Server 2003 computer, the default is to start a new session.
This is how you can connect to the default/console/admin session:
Create a .bat file like this:
%SystemRoot%\system32\mstsc.exe “You RDP file” /admin
For options just run
This post is a good reference
There are few common tasks in SQL server that should work out of the box, but give errors that confuse less experiences developers. Like when you try to restore a backup from another server, you get:
Restore failed for Server ‘.\SQLEXPRESS’. (Microsoft.SqlServer.SmoExtended)
System.Data.SqlClient.SqlError: The backup set holds a backup of a database other than the existing ‘SomeDb’ database. (Microsoft.SqlServer.Smo)
The solution could not be simpler: you should use WITH REPLACE option of RESTORE command, or in SQL Server Management studio select “Options” page and check “Overwrite the existing database (WITH REPLACE)”
SQL Server is smart in selecting great default options for a new database. If you can afford to lose the changes between backups to keep maintenance simple (and in most of non-critical databases it is a reasonable compromise) and you backup your database regularly using a tool like SQLBackupAndFTP, then the “Simple” recovery model (selected by default) is appropriate for you. However if you ever had massive data operations, you may notice that the size of your transaction log (LDF) file is huge. The reason for it is that SQL server does not automatically shrinks the size of transaction log.
To keep log file under control, it may be tempting to enable Auto Shrink option. That would be a mistake – it is an evil option that should always be off. Shrink is a heavy procedure that should only be used rarely.
Instead just run this command to decrease the size of the data and log files to leave 10 percent free space (read more):
DBCC SHRINKDATABASE (YourDatabaseName, 10)
It is not over yet! Most often shrink will increase fragmentation of your indexes. To defragment indexes, you’ll need to use ALTER DATABASE – see this link