We understood that the problem was not with the mssql.domain_name link but the virus alert only happened after click on ASP .NET Enterprise Manager, Recomended this site. And the link was:

www.referralplanet.com/referral/windows/referralWindow.asp?id=17

Since the site was not hosted with us we had a sigh of relief that the problem is not with the server however we thought we still have a security problem if the link has been injected into ASP .NET Manager site in IIS, may be due to a security issue with Plesk control panel. And after checking several servers we came to know that the problem has happened to the site that is recommended on MSSQL Webadmin site and not the server.

If you want to remove this link from your server as well as from the MSSQL WebAdmin site then follow the steps below:

1. Login into the server through RDP with Administrator user.
2. Go to D:\inetpub\vhosts\sqladmin\mssql\app
3. Open the navbar.aspx page in notepad
4. Go to line number 119 and remove the code below:

<!-- Begin ReferralPlanet.com Referral Script -->
<a onclick="refWindow=window.open('http:// www.referralplanet.com/referral/windows/referralwindow.asp?id=18','referralWindow' ,'width=350,height=520,scrollbars=yes,menubar=no,resizable=yes'); refWindow.focus(); return false;" target=_blank href="http:// www.referralplanet.com/referral/windows/referralWindow.asp?id=17">
<IMG alt="Click Here To Tell A Friend" src="images/tellafriend.gif" border=0></A>
<!-- Begin ReferralPlanet.com Referral Script -->

5. Save the file and exit.

This problem must have infected millions of computer in the world. Let see when chinese hacker stop putting their shit on other’s website and get mature.

1. SQLOS: which implements the basic services required by MS SQL Server, including thread scheduling, I/O stat management and memory management.

2. Relational Engine: which implements the relational database components including support for databases, tables, queries and stored procedures as well as implementing the type system.

3. Protocol Layer: which exposes the MS SQL Server functionality.

SQLOS

SQLOS is the base component in the Windows SQL Server architecture. It implements functions normally associated with the Operating System, thread scheduling, memory management, I/O management, buffer pool management, resource management, synchronization primitives and locking, and deadlock detection. Because the requirements of Windows SQL Server are highly specialized, it implements its own memory and thread management system, rather than using the generic one implemented in the OS. SQLOS also includes synchronization primitives for locking as well as monitoring for the worker threads to detect and recover from deadlocks.

SQLOS handles the memory requirements of MS SQL Server as well. Reducing disc I/O is one of the primary goals of specialized memory management in SQL Server. It maintains a buffer pool, which is used to cache data pages from the disc, and to satisfy the memory requirements for the query processor, and for other internal data structures. SQLOS monitors all the memory allocated from the buffer pool, ensuring that the components return unused memory to the pool, and shuffles data out of the cache to make room for newer data. For changes that are made to the data in buffer, SQLOS writes the data back to the disc lazily, that is when the disc subsystem is either free, or there have been significant numbers of changes made to the cache, while still serving requests from the cache. For this, it implements a Lazy Writer, which handles the task of writing the data back to persistent storage.

WIndows SQL Server normally supports up to 2 GB memory on x86 hardware, though it can be configured to use up to 64 GB if the Address Windowing Extension is used in the supporting operating system. For x64 hardware, it supports 8 TB of memory, and 7 TB for IA-64 systems (currently it is limited by Windows Server 2003 SP1 to 1TB). However, when running x86 versions of SQL Server on x64 hardware, it can access 4 GB of memory without any special configuration.

Relational Engine:

The Relational engine implements the relational data store using the capabilities provided by SQLOS, which is exposed to this layer via the private SQLOS API. It implements the type system, to define the types of the data that can be stored in the tables, as well as the different types of data items (such as tables, indexes, logs etc) that can be stored. It includes the Storage Engine, which handles the way data is stored on persistent storage devices and provides methods for fast access to the data. The storage engine implements log-based transaction to ensure that any changes to the data are ACID compliant. It also includes the query processor, which is the component that retrieves data. MSSQL queries specify what data to retrieve, and the query processor optimizes and translates the query into the sequence of operations needed to retrieve the data. The operations are then performed by worker threads, which are scheduled for execution by SQLOS.

Protocol Layer:

Protocol layer implements the external interface to MS SQL Server. All operations that can be invoked on MSSQL Server are communicated to it via a Microsoft-defined format, called Tabular Data Stream (TDS). TDS is an application layer protocol, used to transfer data between a database server and a client. Initially designed and developed by Sybase Inc. for their Sybase MS SQL Server relational database engine in 1984, and later by Microsoft in Microsoft MS SQL Server, TDS packets can be encased in other physical transport dependent protocols, including TCP/IP, Named pipes, and Shared memory. Consequently, access to MSSQL Server is available over these protocols. In addition, the MSSQL Server API is also exposed over web services.

Pros and Cons to Windows 2003 Clustering and Load Balancing:

You could now be asking yourself, which is better to implement, Windows clustering or load balancing hosting? To give you a quick rundown of the high-level pros and cons to each technology, consider the following. With Windows cluster hosting, you depend on the actual clustered nodes to make a decision about the state of the network and what to do in a failure. If Node A in a cluster senses a problem with Node B (Node B is down), then Node A comes online. This is done with heartbeat traffic, which is a way for Node A to know that Node B is no longer available and it must come online to take over the traffic. With load balancing, a single device (a network client) sends traffic to any available node in the load-balanced group of nodes. Load balancing uses heartbeat traffic as well but, in this case, when a node comes offline, the “load” is recalculated among the remaining nodes in the group. Also, with clustering (not load balancing), you’re normally tied down or restricted to a small number of participating nodes. For example, if you want to implement a clustered solution with Windows 2003 Advanced Server, you might use a two-node cluster. With load balancing, you can implement up to 32 nodes and, if you use a third-party utility, you can scale way beyond that number. You can even mix up the operating system (OS) platforms, if needed, to include Sun Solaris or any other system you might be running your services on. Finally, you have the option to set up tiered access to services and to mix both architectures (clustering and load balancing hosting) together. You can set up the first tier of access to your web servers as load balanced and the last tier of access as your clustered SQL databases.

With eukhost we have expertise for any feature as per your hosting requirement. We can also setup Windows Dedicated Cluster hosting along with Plesk control panel, this is something that only eUKhost can provide.

This would only happen if the Cluster services has been installed before installing and configuring MSDTC Service. Hence it is highly recommended that you first install and configure MSDTC and then configure the Windows Cluster Service.

Event ID: 4097
Description:
MS DTC started with the following settings: Security Configuration (OFF = 0 and ON = 1): Network Administration of Transactions = 1, Network Clients = 0, Distributed Transactions using Native MSDTC Protocol = 1, Transaction Internet Protocol (TIP) = 0, XA Transactions = 1.

OR

Event ID: 4395
Description:
MSDTC detected that MSDTC related information in the local registry is different from that in the shared cluster registry. Error Specifics: d:ntcomcom1xdtcsharedmtxclumtxclusetuphelper.cpp:541, CmdLine: C:WINNTSystem32msdtc.exe, Pid: 796
Data:
0000: 05 40 00 80 .@.?

OR

Event ID: 4384
Description:
MS DTC was unable to start because the installation was not configured to run on a cluster. Please run comclust.exe and restart MS DTC. Error Specifics: d:ntcomcom1xdtcsharedmtxclumtxclusetuphelper.cpp:668, CmdLine: C:WINNTSystem32msdtc.exe, Pid: 796

OR

Event ID : 7024
Source : Service Control Manager
Description: The MSDTC service terminated with service specific error 3221229584.

Initially you should try and run the command below and check if it solves the problem:

msdtc -resetlog

If that does not help then follow the fix below:

1. Delete the DTC resource
2. Delete MSDTC folder from the quorum disk.

On Node 1:

– Stop the Cluster Service

– Remove Enable network DTC  Service with the command below:

msdtc -uninstall

Make sure to check the Success in the Event logs.

– Verify that the following registry key has been removed as well.. if not then remove it manually.

HKEY_CLASSES_ROOTCID
HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSDTC
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSDTC

– Reboot the Server

– After the Server is back online reinstall Enable network DTC Service with the command below:

msdtc -install

Now create the DTC resource on Node 1 and it should come online.

Now on Node 2

– Stop the Cluster Services.

– Evict Node 2 from the Cluster

– Remove Enable network DTC  Service with the command below:

msdtc -uninstall

Make sure to check the Success in the Event logs.

– Verify that the registry key has been removed as well.. if not then remove it manually.

– Reboot

– Reinstall Enable network DTC Service with the command below:

msdtc -install

– Verify that the Service has now Started and also registry keys created.

– Rejoin the node back into the cluster.

Software Requirements

•    Microsoft Windows Server 2003 Enterprise Edition or Windows Server 2003 Datacenter Edition installed on all dedicated servers in the cluster.
•    A name resolution method such as Domain Name System (DNS), DNS dynamic update protocol, Windows Internet Name Service (WINS), HOSTS, and so on.

•    An existing domain model.
•    All nodes must be members of the same domain.
•    A domain-level account that is a member of the local administrators group on each node. A dedicated account is recommended.

Hardware Requirements

•    Clustering hardware must be on the cluster service Hardware Compatibility List (HCL). To find the latest version of the cluster service HCL, go to the Windows Hardware Compatibility List at http://www.microsoft.com/hcl/, and then search for cluster. The entire solution must be certified on the HCL, not just the individual components.

•    Two mass storage device controllers—Small Computer System Interface (SCSI) or Fibre Channel. A local system disk for the operating system (OS) to be installed on one controller. A separate peripheral component interconnect (PCI) storage controller for the shared disks.
•    Two PCI network adapters on each node in the cluster.
•    Storage cables to attach the shared storage device to all computers. Refer to the manufacturers instructions for configuring storage devices..
•    All hardware should be identical, slot for slot, card for card, BIOS, firmware revisions, and so on, for all nodes. This makes configuration easier and eliminates compatibility problems.

Network Requirements

•    A unique NetBIOS name.
•    Static IP addresses for all network interfaces on each node.
•    Access to a domain controller. If the cluster service is unable to authenticate the user account used to start the service, it could cause the cluster to fail. It is recommended that you have a domain controller on the same local area network (LAN) as the cluster is on to ensure availability.
•    Each node must have at least two network adapters—one for connection to the client public network and the other for the node-to-node private cluster network. A dedicated private network adapter is required for HCL certification.
•    All nodes must have two physically independent LANs or virtual LANs for public and private communication.
•    If you are using fault-tolerant network cards or network adapter teaming, verify that you are using the most recent firmware and drivers. Check with your network adapter manufacturer for cluster compatibility.

Shared Disk Requirements:

•    An HCL-approved external disk storage unit connected to all computers. This will be used as the clustered shared disk. Some type of a hardware redundant array of independent disks (RAID) is recommended.
•    All shared disks, including the quorum disk, must be physically attached to a shared bus.
•    Shared disks must be on a different controller then the one used by the system drive.
•    Creating multiple logical drives at the hardware level in the RAID configuration is recommended rather than using a single logical disk that is then divided into multiple partitions at the operating system level. This is different from the configuration commonly used for stand-alone servers. However, it enables you to have multiple disk resources and to do Active/Active configurations and manual load balancing across the nodes in the cluster.
•    A dedicated disk with a minimum size of 50 megabytes (MB) to use as the quorum device. A partition of at least 500 MB is recommended for optimal NTFS file system performance.
•    Verify that disks attached to the shared bus can be seen from all nodes. This can be checked at the host adapter setup level. Refer to the manufacturer’s documentation for adapter-specific instructions.
•    SCSI devices must be assigned unique SCSI identification numbers and properly terminated according to the manufacturer’s instructions.
•    All shared disks must be configured as basic disks.
•    Software fault tolerance is not natively supported on cluster shared disks.
•    All shared disks must be configured as master boot record (MBR) disks on systems running the 64-bit versions of Windows Server 2003.
•    All partitions on the clustered disks must be formatted as NTFS.
•    Hardware fault-tolerant RAID configurations are recommended for all disks.
•    A minimum of two logical shared drives is recommended.

Local Group Policy:
Using local Group Policy involves setting up Group Policy on the local machine.This is not very useful for managing computers on a network. Local Group Policy is configured on the local computer.

Site Group Policy:

Site Group Policy is when the Group Policy object is linked to the site. Site Group Policies can generate unwanted network traffic, so use these only when absolutely necessary.

Domain Group Policy:
Domain Group Policy is when the Group Policy object is linked to the domain.This will apply the Group Policy object to all computers and users within a domain.This is especially useful for enforcing company-wide settings.This is one of the two most commonly used applications of Group Policy.

Organizational Unit:
Group Policy When the Group Policy object is linked to the organizational unit (OU). Organizational unit Group Policy is especially useful for applying a Group Policy object to a logical grouping (organizational unit) of users or computers.

When a Windows Server machine logs on to a Windows AD, any legacy Windows 2000 Group Policies will be applied to and work on Windows Server. The new Windows Group Policy snap-in will work on a Windows 2000 AD as well as Windows 2003.You can use the Windows Group Policy snap-in to connect to any Group Policy object in the Active Directory.You can also create a new Group Policy object using this snap-in. When you connect to a GPO using this snap-in, the ADM files are automatically updated using the newer versions of these files found on Windows XP.

Windows has over 200 policies.These policies are reflected in the new ADM files that are updated on the domain.The Windows admin snap-in shows what policies work on which clients. Best practice in a mixed environment: Use the Latest Windows Group Policy snap-in to administer Group Policy because it will display what policies are supported on what clients.

Group Policy Order

When Group Policies are applied in Windows Server, they are applied in a specific order.This is important to note because the order applied can affect the resulting policy. Group Policy is applied in the following order:

■ Windows NT 4 Policies (if any exist)
■ Windows 2000 Policies
■ Local Group Policies
■ Site Group Policies
■ Domain Group Policies
■ Organizational Group Policy Objects (going from Highest Parent in the chain to lowest)

Additionally, the result of all of the applied policies can be determined by using the Resultant Set of Policy (RSOP) snap-in. More information on this topic is covered later in the “Resultant Set of Policy (RSOP)” section. Figure A.1 shows how Group Policy is applied by different organizational units along with the domain Group Policy.

After installing a SQL Server failover cluster, the node hosting the SQL Server resource uses the Service Control Manager to check every 5 seconds whether the SQL Server service appears to be running. This “LooksAlive” check does not impact the performance of the system, but also does not do a thorough check; the check will succeed if the service appears to be running even though it might not be operational. Because the LooksAlive check does not do a thorough check, a deeper check must be done periodically; this “IsAlive” check runs every 60 seconds.

The IsAlive check runs a SELECT @@SERVERNAME Transact-SQL query against SQL Server to determine whether the server can respond to requests. Although a reply to the IsAlive query confirms that the SQL Server service is available for requests, it does not guarantee that all user databases are available, or that the user databases are operating within necessary performance/response-time requirements.

If the IsAlive query fails, the IsAlive health check is retried five times and then it attempts to reconnect to the instance of SQL Server. If all five retries fail, the SQL Server resource fails. Depending on the failover threshold configuration of the SQL Server resource, the failover cluster will attempt to either restart the resource on the same node or it will fail over to another available node. The IsAlive query tolerates a few errors, but ultimately it fails if its threshold is exceeded.

During failover of the SQL Server instance, SQL Server resources start up on the new node. Windows clustering starts the SQL Server service for that instance on the new node and SQL Server goes through the recovery process to start the databases. After the service is started and the master database is online, the SQL Server resource is considered to be up. Now the user databases will go through the normal recovery process, which means that any completed transactions in the transaction log are rolled forward (the Redo phase), and any incomplete transactions are rolled back (the Undo phase). In SQL Server 2005 Enterprise Edition, each user database will be available to the user once the Redo phase completes; for the other editions, as with all previous versions, each user database is unavailable until the Undo phase completes. The length of the recovery process depends on how much activity must be rolled forward or rolled back upon startup. The ‘recovery interval’ sp_configure option of the server can be set to a low number to avoid longer Redo recovery times and to speed up the failover process. The Undo recovery time can be reduced by using shorter transactions so that any uncommitted transactions do not have much to roll back.

Certificates are parallel with asymmetric keys in the SQL Server 2005 encryption hierarchy. A certificate is simply a method of using asymmetric encryption. Certificates bind public keys to individuals who hold the associated private key. Certificates use the same RSA algorithm as asymmetric keys; therefore, they are resource-intensive and their use is normally restricted to encrypting other keys. SQL Server contains an integrated certificate authority, which it uses to issue its own selfsigned, and industry standard X.509 certificates. Alternatively, you can import certificates from an external certificate authority.The use of external certificates allows you to use a wider range of key lengths, which can provide enhanced security. Certificates are the most secure way in which to encrypt data natively within SQL Server 2005.You can use the CREATE CERTIFICATE statement to create a certificate within SQL Server 2005.

The common syntax of the CREATE CERTIFICATE statement is as follows:

CREATE CERTIFICATE CERTIFICATE_NAME [AUTHORIZATION USER_NAME]
{FROM FILE = 'PATH_TO_PRIVATE_KEY'
WITH PRIVATEKEY [, ENCRYPTION BY PASSWORD = 'PASSWORD' |
, DECRYPTION BY PASSWORD = 'PASSWORD']}
WITH SUBJECT = CERTIFICATE_SUBJECT_NAME, |
[START_DATE = MM/DD/YYYY
END_DATE = MM/DD/YYYY]

Here are definitions of the arguments in this syntax:

FILE = PATH_TO_PRIVATE_KEY Specifies the directory and the file name to the private key.
ENCRYPTION BY PASSWORD = ‘PASSWORD’ Specifies the password that will be used to encrypt the certificate private key.
DECRYPTION BY PASSWORD = ‘PASSWORD’ Specifies the password originally used to encrypt the private key.
CERTIFICATE_SUBJECT_NAME A descriptive string that will be embedded into the certificate metadata.
START_DATE Specifies the date in which the certificate becomes valid.
END_DATE Specifies the date in which the certificate expires.

For a full listing of all statement arguments, please refer to SQL Server 2005 Books Online.You will need the CREATE CERTIFICATE permission within the database to create a certificate.The following syntax creates a certificate and encrypts the certificate private key with the supplied password:

CREATE CERTIFICATE Certificate01 ENCRYPTION BY
PASSWORD = '&7YuKj%4@)aSZ@'
WITH SUBJECT = 'Certificate to test encryption',
START_DATE = '8/13/2007',
EXPIRY_DATE = '8/13/2011'

Unlike symmetric and asymmetric keys, certificates can be backed up individually. To back up a certificate, you can use the BACKUP CERTIFICATE statement:

BACKUP CERTIFICATE CERT_NAME TO FILE = 'PATH_TO_FILE'
[WITH PRIVATE KEY
(FILE = 'PATH_TO_PRIVATE_KEY_FILE',
ENCRYPTION BY PASSWORD = 'ENCRYPTION_PASSWORD',
DECRYPTION BY PASSWORD = 'DECRYPTION_PASSWORD')]

Here are definitions of the arguments of this syntax:

CERT_NAME Specifies the name of the certificate to be backed up.
PATH_TO_FILE Specifies the directory path and the filename that will be used for the certificate public key backup.
PATH_TO_PRIVATE_KEY_FILE Specifies the directory path and the filename that will be used for the certificate private key backup.
ENCRYPTION_PASSWORD Specifies the password that will be used to encrypt the certificate private key backup.
DECRYPTION_PASSWORD Specifies the password that will be used to decrypt the certificate private key within the database.

To execute the BACKUP CERTIFICATE you will need the CONTROL permission on the certificate and the VIEW DEFINITION permission on the database. The following syntax uses the BACKUP CERTIFICATE statement to back up both the public and private key of your previously created certificate, and encrypts the private key backup file with a user-supplied password:

BACKUP CERTIFICATE Certificate01 TO FILE =
'C:\backup\certificates\Certificate01.pub'
WITH PRIVATE KEY
(DECRYPTION BY PASSWORD = '&7YuKj%4@)aSZ@',
ENCRYPTION BY PASSWORD = '9UyZ%E!b8%7Ly#',
FILE = 'C:\backup\certificates\Certificate01.prv')

For a complete listing of statement arguments and permission requirements, please see SQL Server 2005 Books Online.To restore a certificate from a backup file, you can use the FROM FILE argument within the CREATE CERTIFICATE statement, which we covered earlier.The following syntax restores your previously backed up public and private key:

CREATE CERTIFICATE Certificate01 FROM FILE =
'C:\backup\certificates\Certificate01.pub'
WITH PRIVATE KEY (FILE = 'C:\backup\certificates\Certificate01.prv',
DECRYPTION BY PASSWORD = '9UyZ%E!b8%7Ly#',
ENCRYPTION BY PASSWORD = '&7YuKj%4@)aSZ@')

Note that if you created Certificate01 previously, you will need to drop the certificate prior to running the preceding syntax.You can obtain a listing of all certificates present in your database by using the sys.certificates view:

Select * from sys.certificates

To change the properties of a certificate you can use the ALTER CERTIFICATE statement:

ALTER CERTIFICATE CERTIFICATE_NAME
REMOVE PRIVATE KEY |
WITH PRIVATE KEY (FILE = 'PATH_TO_PRIVATE_KEY' |
DECRYPTION BY PASSWORD = 'PASSWORD' |
ENCRYPTION BY PASSWORD = 'PASSWORD')
WITH ACTIVE FOR BEGIN_DIALOG = [ON | OFF]

Here are definitions of the arguments of this syntax:

CERTIFICATE_NAME The name of the certificate to be altered.
REMOVE PRIVATE KEY Removes the private key from the certificate.
FILE = ‘PATH_TO_PRIVATE_KEY Specifies the directory and the file name to the private key.
DECRYPTION BY PASSWORD = PASSWORD Specifies the password in which to decrypt the private key.
ENCRYPTION BY PASSWORD = PASSWORD Specifies the password in which to encrypt the private key
ACTIVE FOR BEGIN_DIALOG Enables or disables a certificate for use with Service Broker.

To run the ALTER CERTIFICATE command you will need the ALTER permission on the certificate.The following syntax changes your certificate private key protection method from user-supplied password to database master key:

ALTER CERTIFICATE Certificate01
WITH PRIVATE KEY (
DECRYPTION BY PASSWORD = '&7YuKj%4@)aSZ@')

To encrypt data using the certificate public key, you can use the ENCRYPTBYCERT statement:

ENCRYPTBYCERT (CERTIFICATE_ID, 'PLAINTEXT')

In this statement, CERTIFICATE_ID specifies the ID of the certificate to be used for encryption. PLAINTEXT is the data string you wish to encrypt.

You will need the VIEW DEFINITION permission on the certificate to execute the ENCRYPTBYCERT statement.The following syntax uses the ENCRYPTBYCERT statement to encrypt the supplied string using your certificate:

SELECT ENCRYPTBYCERT(Cert_ID('Certificate01'), 'certificate encryption test')

Here are the results:

0x50BCA9702D6999578923DAEC2B3EE96E69174429EBF54C392A532919679624097CD050110CEEF4DDB3BF
22656549268848C2F6E6BA70C0E543DFB411B654302AB9582A525DB835940FB76F9AAC501BBC5E3D689FB0
431BA7AF3C51A4DCDC5BCB7D101324E466A23447DF916E80D026E2A2E6D5A433E75804ADF8E9B75BF0E097

As we mentioned earlier, the preceding results will differ from what you receive on your SQL Server.To decrypt the cipher text, you can use the DECRYPTBYCERT statement:

DECRYPTBYCERT (CERTIFICATE_ID, 'CIPHERTEXT', CERT_PASSWORD)

Here are the definitions of the arguments of this syntax:

CERTIFICATE_ID The ID of the certificate to be used for encryption.
CIPHERTEXT The string that was previously encrypted with the certificate public key.
CERT_PASSWORD The password that encrypts the certificate private key.

To execute the DECRYPTBYCERT statement, you will need the VIEW DEFINITION permission on the certificate.The following syntax uses the DECRYPTBYCERT statement to decrypt the cipher text and convert the results into the human readable varchar data type:

SELECT CAST (DECRYPTBYCERT(Cert_ID('Certificate01'),
0x50BCA9702D6999578923DAEC2B3EE96E69174429EBF54C392A532919679624097CD050110CEEF4DDB
3BF22656549268848C2F6E6BA70C0E543DFB411B654302AB9582A525DB835940FB76F9AAC501BBC5E3D
689FB0431BA7AF3C51A4DCDC5BCB7D101324E466A23447DF916E80D026E2A2E6D5A433E75804ADF8E9B
75BF0E097)
AS varchar)

Note that you should substitute the cipher text in the preceding statement with the cipher text that you obtained from the earlier ENCRYPTBYCERT statement. Here is what the results of running the preceding statement will look like:

certificate encryption test

When you no longer need a certificate, it can be removed from the database using the DROP CERTIFICATE statement:

DROP CERTIFICATE CERTIFICATE_NAME

In this statement, CERTIFICATE_NAME specifies the name of the certificate to be removed.
To execute the DROP CERTIFICATE statement, you will need the CONTROL permission on the certificate.The following syntax drops your previously created certificate.

DROP CERTIFICATE Certificate01

The following script outlines the certificate encryption process from end to end:

-- Demonstration of certiifcate encryption
-- Create Database
CREATE Database CertEncryptDemo
GO
USE CertEncryptDemo
--
-- Switch to database context
--
-- Create table for data to be encrypted
CREATE Table Customers(
FirstName varchar(30),
LastName varchar(30),
CreditCardNum varbinary(300))
--
-- Create Database Master Key
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '5YtF4$aQ#W4d^W'
--
--** You should backup the Database Master Key immediately after creation! **
--
--Create certificate and use the databse master key to encrypt the private key
CREATE CERTIFICATE Certificate02
WITH SUBJECT = 'Test certificate for encryption',
START_DATE = '1/1/2007',
EXPIRY_DATE = '1/1/2012';
--
-- Populate table with data included encrypted credit card numbers
INSERT INTO Customers Values('Blake', 'Cabbage',
EncryptByCert(Cert_ID('Certificate02'), '342724356361631'))
INSERT INTO Customers Values('Colin', 'Edwareds',
EncryptByCert(Cert_ID('Certificate02'), '4516525615214110'))
INSERT INTO Customers Values('Anoson', 'Monroe',
EncryptByCert(Cert_ID('Certificate02'), '5582858885802510'))
Data Encryption • Chapter 8 241
--
--View the contents of the table
Select * from Customers
--
--View table data including the decrypted plain text credit card numbers
--
SELECT Firstname,LastName, CAST(DecryptByCert(Cert_ID('Certificate02'),
CreditCardNum) AS varchar) as 'CreditCardNum' from customers
--
--Clean-up demo
DROP CERTIFICATE Certificate02;
DROP MASTER KEY;
USE TEMPDB
DROP DATABASE CertEncryptDemo;
--END

EFS can be used to encrypt SQL Server 2005 data files and folders. EFS is supported on Windows 2000 and later operating systems with New Technology File Systems (NTFS) formatted drives. EFS uses a combination of symmetric and asymmetric methods to provide transparent SQL Server 2005 data encryption. On Windows 2003 Server and newer operating systems, EFS by default creates a random File Encryption Key, which is a 256-bit AES key to perform data encryption.The File Encryption Key is then itself encrypted with the user’s public key and stored within the encrypted file or folder.

To encrypt SQL Server 2005 data files and folders using EFS, follow these steps:

1. Stop the SQL Server service.
2. Log out and log in using the SQL Server service account credentials.
3. Right-click on the file or folder to be encrypted and select Properties | General Tab | Advanced.

4. Within the Advanced attributes window, select Encrypt contents to secure data.
5. Within the Advanced attributes window, press OK.
6. Within the Properties tab, press OK.
7. If you are encrypting a folder containing subfolders, you will be presented with another window asking if you would like to  encrypt them as well. Press OK.
8. EFS encrypted files and folder names should now appear in green within any Windows file explorer window.
9. Restart the SQL Server services.

If errors are generated, you may have encrypted the SQL Server data files using an account that is not linked to the SQL Server service account.You can decrypt the data folders by reversing the steps above and trying again. When encrypting individual database files, EFS first creates a plain text copy of the file to be encrypted, encrypts the target file, and then deletes the temporary file.This temporary file is not securely deleted and can be recovered using common data recovery tools. To prevent local file disclosure, you should use a secure data deletion tool to overwrite the areas of disk containing the temporary file. Alternatively, you can simply encrypt the parent folder that contains the database files to ensure any temporary files are also encrypted.

EFS encryption is beneficial if the database media is stolen or misplaced. When transferring EFS encrypted files over the network, Windows first decrypts the file and then transfers the plain text equivalent. Some administrators perform manual backups of database files prior to implementing changes on the database server. If this backup involves copying data files from one server to another, you will effectively be storing an unencrypted copy of your database on the destination server.

Encryption File System Contains Inherit Flaws

On Windows Server 2003, EFS uses a strong 256-bit AES key to encrypt data. Under most circumstances, this would be an effective method of encryption; however, this AES key is protected by the user’s public key, which is based on the user’s Windows login password. This ultimately reduces EFS protection to the strength of the user’s Windows password. There are publicly available tools that can successfully decrypt EFS encrypted data by exploiting this flaw. Because of this, EFS should not be used to encrypt sensitive database data.

Working with EFS Encrypted Data

EFS encryption is managed by the operating system, and seamlessly provides file and folder encryption to SQL Server 2005. All SQL Server functions and operations remain unchanged when using this encryption method. Because EFS is handled outside of SQL Server 2005, encryption keys must be backed up separately in addition to your database backups.

Databases often contain sensitive financial, healthcare, and corporate data. As mentioned earlier, data security breaches are occurring at an alarming rate and international legislations have been passed, which set regulations on how organizations must protect this sensitive data. The Payment Card Industry (PCI), Health Insurance Portability and Accountability Act (HIPAA), Personal Information Protection and Electronic Documents Act (PIPEDA), Gramm-Leach-Bliley Act (GLBA), and the UK Data Protection Act are just a few of these regulations. Several regulations require that sensitive data be encrypted and that organization’s must identify and report data disclosure or misuse. If these regulations are not followed, organizations can face serious repercussions, ranging from financial penalties to imprisonment of responsible parties. Depending on the nature of your business, the above regulations may not apply, but before you discount the need to encrypt data

consider that sensitive information can also include corporate information including confidential HR data, trade secrets, patents, designs, or client listings, which, if disclosed to unauthorized individuals, could have a grave impact on your organization. At this point you may be wondering,“why not just encrypt all data using a secure algorithm?” instead of determining specifically what data elements require encryption.The answer is that there is a  significant performance impact when encrypting data, as SQL Server must perform authentication, encryption, and decryption functions seamlessly to encrypt and decrypt the data. In addition, there are several other side effects associated with data encryption, which we will touch on later in this chapter. For these reasons, you should use data encryption only when required and only on the required data elements.

Ways to encrypt data in MSSQL 2005:

EFS Encryption
Native SQL Server 2005 Encryption
Using Keys to Encrypt Data
Using Certificates to Encrypt Data
Using Pass Phrases to Encrypt Data
Working with Data Encrypted
Indexing Encrypted Data
Replicating Encrypted Data
Symmetric Key Usage Tracking
Replicating Encrypted Stored
Using Endpoint Encryption

BEST PRACTICES ACCORDING TO MICROSOFT

• Install only those components that you will use immediately. Microsoft recommends that you create a list of components that you will be using, and only enable those. If the need arises, you can install the additional components at that time. The components in a SQL Server installation are the Database Engine, Analysis Services Engine, Reporting Services, Integration Services, Notification Services, and Documents and Samples.

• Enable only the optional features you will use, and review optional feature usage before doing an in-place upgrade and disable unneeded features. Microsoft recommends that you create a list of the optional features that you will use, and only turn those on. If this is an existing SQL Server that is being upgraded, they recommend creating the same list, and disabling any optional features not on the list. These optional features are CLR Integration, OLE Automation, remote use of a dedicated administrator connection, Database Mail and SQL Mail, OpenRowset and OpenDataSource functions, SQL Server Web Assistant, and xp_cmdshell availability.

• Develop a policy with respect to permitted network connectivity choices and for the usage of optional features. Microsoft recommends defining policies that would be company wide on Connectivity Choices and the use of optional features. They also recommend using SQL Server Surface Area Configuration to standardize this policy and documenting exceptions to the policy on a perinstance basis.

• Turn off unneeded services by setting the service to either Manual startup or Disabled. Microsoft recommends going into the service management area and setting all services that you will not be using.

MS SQL 2005 Server was released after 5 servers of it previous SQL version, MS SQL 2000, Hence it required allot to revisions to cope up with the current windows development environment. Therefore MS SQL 2005 SP2 had major changes in it, with too many performances and security fixes. Microsoft could not add few revisions due to its basic development structure however they had all the scope to introduce them in SQL 2008 release. And indeed, MS SQL 2008 has many installation as well as performance fixes being applied to it and allowing Windows Administrators to have full control on SQL activities. The biggest advantage of SQL 2008 over SQL 2005 is the ability to manage and maintain server performance. SQL 2008 does not require too much resource which is the best deal for today’s Shared Hosting environment. Also an upper hand to whose to do not want to invest too much on hardware of their dedicated servers just to run SQL server on it.

I have tried to gather the major improvement introduced by Microsoft on SQL 2008 from Internet which is an advantage over SQL 2005 however it all depends on what features are useful to you in the development of your ASP .NET applications. But switching to Microsoft SQL 2008 is definitely going to improve the performance even if you don’t use any of the below feature. And not to forget that with the release of SQL 2008, Microsoft will announce “End Of Life” for SQL 2000 version, which will mean that there won’t be any official support or update release for SQL 2000.

Major difference between SQL 2005 and SQL 2008.

* Easy Upgrades: Version upgrades are now very easy and effective with SQL 2008.
* Resource Restriction Governor: We set a restriction on a users or groups from consuming high resources. This is a very good feature that can be used on Windows shared server with SQL database to maintain the performance.
* Dates and Times settings: New data types such as: Date, Time, Date Time Offset has been introduced.
* Improved Full Text Search: Ability to backup Native Indexes and also thesaurus them as metadata.
* External Key Management: This unique can store Keys separately and not with the data.
* Improved SQL Server Analysis Service: It now has improved Stacks and computes block faster.
* Improved Installation: Microsoft has added an option where you can uninstall Disk images and service packs.
* Data Synchronizing: A Development of databases used in applications that frequently get disconnected.
* Transparent Data Encrypts: It has the ability to encrypt full SQL database with different encryption Methods.

* SQL Server Integration Service: SQL 2008 Server has improved multiprocessor support and faster lookups in compare to SQL 2005.
* Change Data Capture: Allows all changes to be captured and queried. (Enterprise). Also allows us to get detailed information on what changes has happened to which rows after a specific version.
* LINQ: A Development query language for accessing multiple type of data like XML and SQL at the same time.
* Hot Plug CPU: With this feature to an add CPUs on fly for your SQL server to use.
* Microsoft Office 2007 integration: One can use MS OFFICE as an SSRS template, like SSRS to WORD.
* Spatial Data types: Data types for storing Longitude, Latitude and GPS entry of a particular database.
* MERGE: A new TSQL command as a combination Update, Insert and Delete.
* Encrypted Backups: We can execute it at the time running backups to prevent tampering from external resource.
* Data Compression: This feature is different as it allows us to manage data compression at table level to enhance performance.
* Dynamic Development: Latest Visual Studio and ADO options along with ASP .Net 3.
* Reporting Server Performance: Unlike in SQL 2005 we can set threshold on Reporting server for memory management.
* Performance Studio: It is a Gallery that has collection of monitoring tools enhanced performance.
* Audits: A very power feature for monitoring the data access of your SQL database.
* Table Value Parameters: SQL 2008 database has ability to insert entire table into a stored procedure.
* Entity Database Services: (LOB) Line Of Business framework and (eSQL) Entity Query Language.

No doubt that Microsoft has improved all the features that has been used by hosting services. Even SQL Cluster in version 2008 has few major advantages since every one in today world wants to have their site up all the time with 100% uptime. I hope I get some time to write on “MS SQL 2008 Clustering..“

• Click Start >> Run, to open the Run dialog box
• Here, type regedit to open the registry.
• Navigate to the following registry key – HKEY_LOCAL_MACHINE >> System >> CurrentControlSet >> Services >> NetBT >> Parameters
• On the right-hand pane find the option TransportBindName.
• Double
  click on TransportBindName and delete the existing default value.
• 
  click Ok

From the above, it is clear, that you have closed Port 445 by giving a blank value to TransportBindName for NetBT services.

close Port 135:

• Click Start >> Run, to open the Run dialog box
• Here, type regedit to open the registry
• Navigate to the following registry key – HKEY_LOCAL_MACHINE >> software >> microsoft >> Ole
• On thee right hand window pane find an option called EnableDCOM
• Double-click EnableDCOM and change the value from Y to N
• click Ok
• Close the Registry Editor and restart your computer

These steps will only work for a standalone servers. Any serveres that are in a cluster state such as Active Directory, SQL failover cluster, Network Load Balancing [NLB] or Windows Replication service that NEVER-EVER follow these steps as it will simply diable port 135 which is used my Distributed File System [DFS] for the servers to comunicate with each other. Disabling it will just wont allow the servers to communicate and the services will fail.

We have seen allot of people looking to have the best option to secure the connection string in their ASP .NET code to connect the MS SQL database since it contains the username and password of their database. It is very important to use a secure method for corporate clients and those who save Credit Card details in their MS SQL database. Or they will easily get hacked and all the important data will be exploited by the hacker. And also for those who store important data in MSSQL.

Here are the list of methods that can be used to secure your MS SQL connection string in your ASP.NET application.

METHODS:

1. Using a DSN connection string:

If you have the administrator users access to your Windows Server or use a control panel like Plesk then you can create a DSN with ODBC connector that stores the password of your database along with its name.

You will have to go to Start >> Administrative Tools >> Data Sources (ODBC) on your Windows Server with an account that has administrative privileges.

Or if you use a hosting control panel like Plesk that you can create the DSN from the control panel itself.

Once you have created the DNS you will have to mention it in your code as:

oConn.Open "DSN=mySystemDSN"

2. Store your connection string either in web.config or global.asa:

It is safe to have connection string stored in either web.config or global.asa, since IIS does not allow these files to be accessed from the browser. But it is recommended to enable custom errors in web.config or else the browser just displays the exact exact in the event of an error.

An example of web.config would be:

3. Encrypt your connection String stored in Web.config.

To make the connection string more secure you can encrypt your string if you application is written in ASP .NET 2 as this only possible with the new feature in asp.net 2.0 through the config API.

Steps to Encrypt your connection string in web.config:

– Create a connectionstring section in web.config :-

– Run the command below:

aspnet_regiis –pe -app optionally you can provide the machine or user store.

– Get the connection string:-

Response.Write(ConfigurationManager.ConnectionStrings

["Myconnstr"].connectionString.ToString());

– You can also encrypt:

– To decrypt the connection string use aspnet_regiis –pd with the same parameters.

– There are more option available, such as:

aspnet_regiis –pef
aspnet_regiis -pdf

4. Save the connection string in the Windows registry:

You can also save the connection string in the windows registry, the only problem here is you have to give appropriate permissions on the registry so that your web user is able to read the data fron the registry:

Procedure to follow:

Add a registry key for your application under SOFTWARE/[YOUR_COMPANY]/[YOUR_APP]
Add a string value for ConnectionString
Teach your ConnectionFactory to crack open the appropriate registry key (in a static constructor, not every page load).
Export the registry info as a .reg file, add it to source control, modify and apply it as necessary to set up additional machines.

You will also have to make sure that the user have appropriate rights on the register to read the data.

5. Save your connection string in a DLL.

You can also save the connection sting the to a DLL using Visual Studio but this includes few disadvantages like, you will gave to decrypt the DLL to make any changes in the connection string and then again encrypt it. This makes things very complicated for you to manage your applications and specially when you have a shared hosting package.

You must enable remote connections for each instance of SQL Server 2005 that you want to connect to from a remote computer. To do this, follow these steps:

1.    Click Start, point to Programs, point to Microsoft SQL Server 2005, point to Configuration Tools, and then click MS SQL Server Surface Area Configuration.
2.    On the MS SQL Server 2005 Surface Area Configuration page, click Surface Area Configuration for Services and Connections.
3.    On the Surface Area Configuration for Services and Connections page, expand Database Engine, click Remote Connections, click Local and remote connections, click the appropriate protocol to enable for your environment, and then click Apply.

Note Click OK when you receive the following message:
Changes to Connection Settings will not take effect until you restart the Database Engine service.
4.    On the Surface Area Configuration for Services and Connections page, expand Database Engine, click Service, click Stop, wait until the MSSQLSERVER service stops, and then click Start to restart the MSSQLSERVER service.

Enable the SQL Server Browser service

If you are running MS SQL Server 2005 by using an instance name and you are not using a specific TCP/IP port number in your connection string, you must enable the SQL Server Browser service to allow for remote connections. For example, MS SQL Server 2005 Express is installed with a default instance name of Computer Name\SQLEXPRESS. You are only required to enable the SQL Server Browser service one time, regardless of how many instances of SQL Server 2005 you are running. To enable the MS SQL Server Browser service, follow these steps.

Important These steps may increase your security risk. These steps may also make your computer or your network more vulnerable to attack by malicious users or by malicious software such as viruses. We recommend the process that this article describes to enable programs to operate as they are designed to, or to implement specific program capabilities. Before you make these changes, we recommend that you evaluate the risks that are associated with implementing this process in your particular environment. If you choose to implement this process, take any appropriate additional steps to help protect your system. We recommend that you use this process only if you really require this process.

1.    Click Start, point to Programs, point to Microsoft SQL Server 2005, point to Configuration Tools, and then click SQL Server Surface Area Configuration.
2.    On the MS SQL Server 2005 Surface Area Configuration page, click Surface Area Configuration for Services and Connections.
3.    On the Surface Area Configuration for Services and Connections page, click SQL Server Browser, click Automatic for Startup type, and then click Apply.

Note When you click the Automatic option, the SQL Server Browser service starts automatically every time that you start Microsoft Windows.
4.    Click Start, and then click OK.

Note When you run the MS SQL Server Browser service on a computer, the computer displays the instance names and the connection information for each instance of SQL Server that is running on the computer. This risk can be reduced by not enabling the SQL Server Browser service and by connecting to the instance of SQL Server directly through an assigned TCP port. Connecting directly to an instance of SQL Server through a TCP port is beyond the scope of this article. For more information about the SQL Server Browser server and connecting to an instance of SQL Server, see the following topics in SQL Server Books Online:

•    SQL Server Browser Service
•    Connecting to the SQL Server Database Engine
•    Client Network Configuration

Create exceptions in Windows Firewall

These steps apply to the version of Windows Firewall that is included in Windows XP Service Pack 2 (SP2) and in Windows Server 2003. If you are using a different firewall system, see your firewall documentation for more information.

If you are running a firewall on the computer that is running SQL Server 2005, external connections to SQL Server 2005 will be blocked unless SQL Server 2005 and the SQL Server Browser service can communicate through the firewall. You must create an exception for each instance of SQL Server 2005 that you want to accept remote connections and an exception for the SQL Server Browser service.

MS SQL Server 2005 uses an instance ID as part of the path when you install its program files. To create an exception for each instance of MS SQL Server, you must identify the correct instance ID. To obtain an instance ID, follow these steps:

1.    Click Start, point to Programs, point to Microsoft SQL Server 2005, point to Configuration Tools, and then click SQL Server Configuration Manager.
2.    In SQL Server Configuration Manager, click the SQL Server Browser service in the right pane, right-click the instance name in the main window, and then click Properties.
3.    On the SQL Server Browser Properties page, click the Advanced tab, locate the instance ID in the property list, and then click OK.

To open Windows Firewall, click Start, click Run, type firewall.cpl, and then click OK.

Create an exception for MS SQL Server 2005 in Windows Firewall

To create an exception for MS SQL Server 2005 in Windows Firewall, follow these steps:

1.    In Windows Firewall, click the Exceptions tab, and then click Add Program.
2.    In the Add a Program window, click Browse.
3.    Click the C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe executable program, click Open, and then click OK.

Note The path may be different depending on where SQL Server 2005 is installed. MSSQL.1 is a placeholder for the instance ID that you obtained in step 3 of the previous procedure.
4.    Repeat steps 1 through 3 for each instance of SQL Server 2005 that needs an exception.

Create an exception for the MS SQL Server Browser service in Windows Firewall

To create an exception for the SQL Server Browser service in Windows Firewall, follow these steps:

1.    In Windows Firewall, click the Exceptions tab, and then click Add Program.
2.    In the Add a Program window, click Browse.
3.    Click the C:\Program Files\Microsoft SQL Server\90\Shared\sqlbrowser.exe executable program, click Open, and then click OK.

Note The path may be different depending on where MS SQL Server 2005 is installed.

A password that allows for spaces can be referred to as a pass phrase. The benefit of pass phrases is that you can make them meaningful and easy to remember. Instead of creating and managing encryption keys or certificates in your database server, you can encrypt data using only a pass phrase.The ENCRYPTBYPASSPHRASE statement uses the supplied pass phrase to generate a symmetric key, which is used to perform the actual data encryption. No key management is required, as the key will be recreated each time the same pass phrase is supplied.The common syntax of the ENCRYPTBYPASSPHRASE statement is as follows:

ENCRYPTBYPASSPHRASE ('PASSPHRASE', 'PLAINTEXT')

In this statement, PASSPHRASE specifies the data string to be used to derive an encryption key. PLAINTEXT specifies the data to be encrypted. No permissions are required to run the ENCRYPTBYPASSPHRASE statement.

The following syntax encrypts the string using the supplied pass phrase:

SELECT ENCRYPTBYPASSPHRASE('SQL Server 2005 Pass Phrase Encryption', 'pass phrase encryption test')

Here are the results:

0x01000000B0FA66E0152FB0B655B23439904E36F3ED5B758618BEED0F2A2BF918C6CF9DF685BC2A60A
AD5E81D660BA5A396D1CA89

As mentioned earlier, the preceding results will differ from what you receive on your SQL Server.To decrypt data, you can use the DECRYPTBYPASSPHRASE statement.The general syntax of this statement is as follows:

DECRYPTBYPASSPHRASE ('PASSPHRASE', 'CIPHERTEXT')

In this statement, PASSPHRASE specifies the data string to be used to derive a decryption key. CIPHERTEXT specifies the data to be decrypted. Similar to the ENCRYPTBYPASSPHRASE statement, no permissions are required to execute the DECRYPTBYPASSPHRASE statement.The following syntax uses the DECRYPTBYPASSPHRASE statement to decrypt the previously encrypted data, and converts it into the human readable varchar format:

SELECT CAST (DECRYPTBYPASSPHRASE('SQL Server 2005 Pass Phrase Encryption',
0x01000000B0FA66E0152FB0B655B23439904E36F3ED5B758618BEED0F2A2BF918C6CF9DF685BC2A60A
AD5E81D660BA5A396D1CA89) AS varchar)

Note that you should substitute the cipher text in the preceding statement with the cipher text that you obtained from the earlier ENCRYPTBYPASSPHRASE statement. Here is what the results of running the preceding statement will look like:

pass phrase encryption test

The encryption algorithm and key length used by pass phrase encryption have not been formally documented by Microsoft. Because of this, it is recommended that you do not use this encryption mechanism to encrypt sensitive data.

Flaws within Microsoft Object Encryption

The object encryption used by Microsoft is weak, and there are publicly available scripts that can successfully decrypt the objects. Further, at run-time, SQL Server internally decrypts the object and SQL Profiler can be used to capture object logic in plain text form. Due to this, object encryption should not be used to encrypt sensitive information, and you should not embed key or certificate passwords or pass phrases in SQL Server objects encrypted using objectbased encryption.

“SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [T:\MSSQL\DATA\%file_name%] in database [%DB_name%] (2).  The OS file handle is 0×00000838.  The offset of the latest long I/O is: 0x000000ebdc0000“

Do you refer it to as a stalled IO? We always hear a questions such as, what’s wrong with SQL Server..? Why is SQL taking so long to read or write to the disk..? Let us discuss why it is not a MS SQL Server problem:

MS SQL Server does data file reads and writes almost exclusively as asynchronous IO, using the win32 APIs ReadFile, WriteFile, ReadFileScatter and WriteFileGather. Each of these APIs behave in a fairly similar steps, the caller sends in a handle to the file, some memory location to read or write, the size of the block and a structure that tells the kernel how to handle the IO. In MS SQL Server’s case, how to handle the IO is Asynchronously, please.  The call returns immediately so that the thread issuing so that the IO can get out of the way and make life happy for other users who are also waiting got their query to return.

The catch here is that, ordinarily the time between the Asynchronous call to read or write and the completion of the read or write should be on the order of 10ms. The longer it takes for an IO to return the more noticeable a performance impact there is to end users.

Prior to MS SQL Server 2000 SP4 the only way you would be able to tell if your IOs were taking longer than expected would be to use System Monitor and watch the PhysicalDisk\Avg Disk sec./read, write and transfer counter.  This is a relatively acceptable method when the cause of your IO bottleneck is the latency of the physical disk, you might be surprised to find out that’s not the only thing that might slow down an IO!

Once a user mode application issues an IO request it’s the equivalent of putting a package in the mail, there’s nothing to do but wait.  While you may not have anything to do once you’ve dropped the package the parcel carriers job has just begun, what with all the processing and labeling and transit – you get the idea.  Likewise for the kernel.  Once an IO transitions over to kernel mode it’s transformed into something called and IRP (interrupt request packet) and begins a trek down levels of filter drivers, virus scanners  and device drivers before it finally makes its way home to a physical device.

Windows exposes methods for device and software manufactures to be notified of, and participate in, IOs.  Filter drivers are one method of doing this, and it allows for great functionality of verifying you aren’t writing a file with a virus pattern, or backing up a file as it’s being written.  The problem here is that the filter driver can hold up an IO for an extended period of time, and this time isn’t reflected in the Sysmon counter.

So what are you to do? You’ve put your specially crafted package in the mail, but the intended recipient still hasn’t got it.

The approach taken in MS SQL Server is to make note of the time the IO started, the offset of the IO within the file then check back a short time later to make sure all IOs have completed.  If an IO is still outstanding and 15 seconds have elapsed then the warning is printed to the errorlog to alert the system administrator that something’s amiss.

When you see this message the first thing you need to check is the physical disk counters in sysmon to ensure that the disks are servicing IOs in a reasonable period of time.  If those appear to fine then start looking at what filter drivers are installed on your system, are there any known issues with them, or just disable them if you don’t need them.