0x80074E24 FWX_E_CONNECTION_KILLED in ISA Server 2004 / 2006

We have recently installed a Samsung SHR-5040 digital video recorder (DVR) in our remote workshop in order to monitor activities and the evolution of customers' orders. We have our branch (workshop) and central offices connected by using a VPN, maintained by two ISA Servers. We thought that making the live output of the DVR available in our central office would be straight away but it was not so simple as it seemed at first.

After having the device set up and running, we checked that the web administration page was available from the sub-net at the branch site. It was Ok. Then, we tried to access the device web page from a computer located at central offices sub-net and, even though the http content (page) was shown, the device was not available using RTSP (Real Time Streaming Protocol) and no live image was shown, only a big black screen and a message saying 'no response'.

Since we had no idea where the problem was (which one of the ISAs, at the branch or at the central site) we started to do the checks step by step, and the first step was the ISA at the branch site (workshop). We started a live log filtering by destination IP being the IP assigned to the DVR and we saw a Connection denied error for RTSP on port 554 (destination) and TCP port 58907 (at the source): 0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED.

After a little research I found that error is raised whenever a new TCP session is attempted without a SYN flag that must be set on the first packet coming from the host trying to start the connection. If ISA receives a packet that does not belong to an existing connection, it must have SYN flag enabled or it will be rejected.

Right before that Connection denied error (and with the same timestamp) we had another log entry, thought not an error, it was quite interesting: Connection close for RTSP on port 554 (destination) and also TCP port 58907 (at the source) 0x80074e24 FWX_E_CONNECTION_KILLED. It was not marked with red color as being an error but it was really weird that the source port for both log entries be the same, at the same time, and first, ISA kills the connection and next ISA says that a new connection (coming from the same host and the same port) without SYN is received and, hence, rejected.

The real problem was not the 0xc0040017 error due to un-synched packed, but the previous entry, the 0x80074e24 that kills the connection unilaterally.

We even added a new access rule to ISA server allowing all protocols from internal network to local host without any luck; still the same behavior was shown: first the connection is killed and then the rest of packets are rejected since they do not belong to an existing connection and do not have sync flag set.

After several days of research and trial and errors we found a post asking for help with the same symptoms that we had: SMTP server rule breaks incoming connections then rejects packets. The only difference was that we were trying to set a DVR instead of a mail server. At the end of the entry we could read:

Unbinding the SMTP application filter from the SMTP server firewall rule changes the "connection killed" message to "abortive shutdown", but the behavior seems otherwise the same.

We also found another old post RE: RTSP - ISA 2006 were we could read:

After upgrading from ISA 2004 to ISA 2006, my streaming media server
stopped working through the firewall. I then noticed in the logs that my RTSP
Server Publishing rule was showing the code for connection killed. I then went
and removed the RTSP filter from the RTSP Server protocol definition, and my 
streaming media started working again. Since I don't see any way of configuring the RTSP filter, and since it worked fine in ISA 2004, I'm guessing that this is a bug in ISA 2006?

This last post was dated on Oct 2006 and we thought that, in case of a bug, it might have been solved already, but we wanted to give it a try.

We went to ISA Server 2006 admin console, browsed though the protocols until we found RTSP, right click, properties, parameters and simply removed RTSP filter from application filters. We then accepted and applied the changes and everything worked like a charm.

Keywords:
ISA Server 2004, ISA Server 2006, streaming, RTSP, RTSP filter, 554, 0x80074e24, FWX_E_CONNECTION_KILLED, 0xc0040017, FWX_E_TCP_NOT_SYN_PACKET_DROPPED, digital video recorder, DVR, Samsung SHR-5040.

Illegal characters in path deploying to SharePoint

I recently started doing tests with SharePoint and I reached the point where I needed doing my own WebPart and debug it. I read about setting a development environment for WSS 3.0 in The .NET Addict's Blog: Setting up your SharePoint 2007 Development Environment. Summing up (changing slightly his suggestions), I needed a spare computer or virtual machine to:

• Install Server 2003 R2, with IIS, SP2 and updates
• Install an instance of SQL Server 2005 Standard Edition
• Install Microsoft .NET Framework 3.0 Redistributable Package
• Install Microsoft Windows SharePoint Services 3.0 with Service Pack 1 (WSS3.0SP1) not in standalone mode.
• Install Visual Studio 2005 and Service Pack 1
• Install Microsoft Windows SharePoint Services 3.0: Software Development Kit (SDK)
• Install Microsoft Windows SharePoint Services 3.0 Tools Visual Studio 2005 Extensions
• Install Microsoft Visual Studio 2005 extensions for .NET Framework 3.0 (Windows Workflow Foundation)

After a couple of days I had the virtual environment ready and tried to create my very first Web Part using the Web Part template installed in the previous steps: I just removed a comment so that the Web Part returned "Output HTML":

public class Web_Part1 : System.Web.UI.WebControls.WebParts.WebPart
{
    public Web_Part1()
    {
        this.ExportMode = WebPartExportMode.All;
    }

    protected override void Render(HtmlTextWriter writer)
    {
        // TODO: add custom rendering code here.
        writer.Write("Output HTML");
    }
}

Compiled, tried to deploy... and the following error appeared:

Creating solution ... 
System.ArgumentException 
Illegal characters in path.

No more information, no trace in the EventLog, nor any other log. What path? What character(s)?

I googled for this problem and found a a page that finally drove me in the right direction:

In System.ArgumentException: Illegal characters in path, they talk about Latin characters (my native Operating System, VS2005 and WSS3.0SP1 are Spanish too). They suggest using encoding iso-8859-1 instead of UTF-8 in XML files... but since those files are created by the tools extension add-in (not mine) I could not manage to do any changes there. But they were right in pinpointing that character outside the standard ASCII character set range of 0x00 - 0x7F might be causing the problem.

Even thought his problems were related to a WebService, the idea of the extended characters was interesting. However, none of my files had any of those. I even re-created the simple project and solution right beneath the root C:\ and the problem still appeared: Illegal characters in path.

After some hours I changed the perspective. If VS2005 cannot tell me which file/path has illegal characters, let's do other tool tell me: Process Monitor. For those of you that do not know this tool, Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity.

I started Process Monitor, filtered by process name devenv.exe (Visual Studio) and tried to do a deploy. Of course it failed again, but then I changed to Process Monitor window and started to scroll and read.

After some minutes I found it! VS2005 was trying to create some files at a temporary directory, pointed by both TMP and TEMP environment variables. They were set to: C:\Documents and settings\myusername\Configuración local\Temp

There was the extended character ó in Configuración. This directory in English systems is: C:\Documents and settings\myusername\Local settings\Temp

After knowing that, all I had to do is changing the user environment variables TMP (and TEMP, just in case) to any other directory not containing any special characters, C:\TEMP for instance. You can do it right clicking on My PC, Properties, Advanced options, Environment variables button, and modify...

I then restarted VS2005 and everything was compiled and deployed without any problem.

Keywords: Visual Studio 2005, VS2005, deploy, WSS3.0, Sharepoint Services, Web Part, development, error, solution, illegal characters in path, caracteres no válidos en la ruta de acceso, implementar

Chain e-mail traffic forwarded by your own internal users... is this spam?

This entry is not about anything related to Microsoft nor any of its products. I work for a medium size company as dba, but there are also other things that I have to handle in a daily basis. One of these things is the e-mail server. It does not matter which product/vendor we use, the problem more general than that. We all know what spam is, there are lots of protecting schemes out there: SPF, DKIM, SenderID, and many more, but... what happens when the email that is consuming your bandwidth is generated from the inside, from your own users?

Of course it is a good idea to have and let your employees know that your company has a Employee Internet Usage Guidelines, or Acceptable Usage Policy. That policy document might start with This policy explains what is classified as the acceptable and unacceptable use of the Internet and e-mail systems..., but how do you enforce that? That is the main question: How do you enforce your e-mail policy?

If your company host email servers on its own servers, your bandwidth will be an issue. Download bandwidth is relatively cheap, but not so the upload. If an employee receives a chain email, with a video attachment (those are becoming more and more popular) of 2.5Mb average, that will have some associated costs, but the big cost (from the point of view of IT staff) will raise afterwards, then that employee decides to forward that amusing Videos / Jokes / PowerPoint presentations / Documents / Images to his/her 15 friends and 5 relatives and the dog. When your email server tries to upload the forwarded email to 20 recipients (fortunately his/her dog does not have an email account yet), your SMTP server queue will grow in 50Mb, and your upload bandwidth will collapse for some/several minutes.

If the Internet connection in your company is shared by other users/services, i.e. web servers, dns, VPNs, VoIP, file replication between branch/main offices, etc. all your users/services will suffer some kind of delay during those peak minutes due to a single user violating (at least) the netiquette.

We have been suffering for a while because of this problem and some problematic employees. No matter if you warn them, after some months, they (or others) will collapse again the server up to the point that any other user comes/calls to the IT department and asks if there is any problem with the Internet connection, because it sucks, or that a annoyed customer has called because he has not received the email that someone promised that it was delivered 2 hours ago. Then we open the monitoring graphs, see the upload peak in the email server, go and see the queue and voila!, there are tons of pending legitimate emails waiting to be delivered because, at some point, the outbound queue has 30 email (of non work related) summing 80Mb to be delivered.

There is an article (dated 2003) that states that 35% of corporate e-mail is non-work related. And I wonder... 35% of emails means 35% of the bandwidth used or 35% of the number of emails? If 35% of the number of emails, that would easily make 40-50% of the bandwidth due to the sizes of the attachments. And the figures are growing day by day... as you can see in another article dated March 2007 which states that Half of corporate web traffic not work related. Companies are failing to enforce their Acceptable Usage Policies, basically because (in case of email, at least), there are no embedded tools to help on this subject.

ISV and MTA are fighting against spam thinking that the enemy is out there, that the bad guys are at the other side of our firewall, but that is only partly true. Legit users inside your companies are are the other part of the problem.

I've been thinking a while on this subject and found a common pattern with those chain e-mails with huge attachments:

1. A file with relatively big size attachment(s) comes into our email server.
2. It comes from a legit user outside our company and the To: list has several recipients.
3. After a short amount of time (from minutes to 72 hours), the same attachment(s) are send out of the company
4. In this case the receipts are different, but there are also more than 3 in most cases.

Having this pattern in mind, we have created a filter that does the following:

For incoming emails

1. If the message has attachments and the size of the message exceeds certain threshold, an MD5 hash is computed for every attachment.
2. A daily log file is created to store MD5 hash, file size, the file name of the attachment, To and From fields. This file stores ONLY incoming content.

For outgoing emails

1. If the message has attachments, the number of recipients is above certain number and the size of the message multiplied by the number of recipients is above a given threshold, MD5 hashes are calculated for every attachment in the email.
2. Every MD5 hash is checked against the known MD5 hashes in the last n days log files.
3. If a match is found, the filter notifies the MTA (.exe program exits with ErrorCode 1) and the outgoing email can be quarantined/deleted/moved to a lower priority queue (the action depends of the MTA filter options).

We found that this approach is smarter than just forbidding certain extensions to be delivered through your email server. Many email servers have options to block certain types of attachments, i.e. block .pps files, or .mp3 files, but sooner or later you will face a case in which a legit user needs to send a legit content of these blocked file types. This is a different approach and relies on the idea of forbidding to send out any content that is not original/originated/created at your site (self-made content), fine-tuned with certain parameters such as n retention days, number of recipients, attachment sizes, out queue threshold, etc. This filter is content-agnostic, it does not matter which file name or content type the attachment is, and, as long as it has the same MD5 hash and had been previously received within the defined time-span, the email will be pinpointed.

Keywords:
bandwidth waste, chain emails, SMTP, queue, upload, productivity losses, filter, quarantine, enforce internet usage policy, free, algorithm, procedure, method

Access 2007: Digital signatures are lost in ADE files

Some weeks ago I posted the following message in microsoft.public.access.security. Here I will reproduce and extend it, since I have not received any response there, to spread the words and reach a higher audicence. Maybe someone would give me a hint some day...

I also made a translation of this article in spanish called Access 2007: La firma digital se pierde cuando se compacta un .ADP o se crea un fichero .ADE

We have been using digital signatures for years (Office 2003) to deploy MS Access complied project files (.ADE) to avoid users to accept security warnings every time they opened the application.

Now we are using Office 2007 and whenever we create ADE files (with signed VB code), we receive (in Access status bar, on the bottom) the following warning (maybe the warning is not exactly as this, since it is a self-made translation from Spanish):

"The changes made to the databes or project had invalidated the linked digital signature"

"Las modificaciones realizadas en la base de datos o proyecto han invalidado la firma digital asociada." (this is the original warning).

After that, when any user tries to open the created ADE file, they receive the usual warning as if the file had no digital signature at all:

Microsoft Office Access Security Notice A potential security concern has been identified. Warning: it is not possible to determine that this content came from a trustworthy source. You should leave this content disabled unless the content provides critical functionality and you trust its source.

That dialog confirms that the original warning shown in the status bar was right. The signature is lost when you compile the ADP into an ADE file.

I have checked that this happens when creating a brand new database project:

1. Create a new database project (ADP) and connect it to any SQL Server / Northwind you have at hand.
2. Create a form with a single button in it and use the following code:

   Option Compare Database
   Option Explicit
   Private Sub Command0_Click()
   MsgBox ("this is a test")
   End Sub

3. Sign the code: Tools -> Digital signatures...
4. Create ADE
5. Try to open the ADE you created before

Can this be classified as a bug or a feature? Is there any place to submit feedbacks for Access 2007?

Thanks in advance.

To this post, and after having done more tests, I would also say that a similar behaviour is shown whenever you compact and repair an ADP file the digital signature is lost too.

It does not matter that there are alternative ways to prevent the security warnings from appearing (i.e. Trust Center). I think this is a real bug that prevents anyone that owns a Digital Certificate from signing and distributing code (without distributing the code, i.e. ADE files) the way we were used to do with Access 2003.

I hope staff at MS solve it better sooner than later. I'm also willing to hear from your experiences on this field.

Links

Access 2007: Digital signature is lost when you create ADE files in Access Security

Access 2007: La firma digital se pierde cuando se compacta un .ADP o se crea un fichero .ADE

Access 2007: Digital signatures are lost in ADE files in Access Database General Questions

Access 2007: Digital signatures are lost in ADE filesin Access ADP SQL

#N/A displayed in cells in Analysis Services 2005

Some days ago I realised that, after having created a Cube reader role and after having granted read access on the cubes, the some data was not still available and the cells showed a #N/A message under particular conditions. The problem arose when the user dragged a measure (any) to the center of the table and then a dimension (any) to the filter area, and then used the filter to select everything but a single dimension value.

If the filter was not showed or not used (selected everything) the measure was display correctly, but if a single dimension value was excluded from the calculation, the #N/A message appeared.

I immediately thought of this problem as a lack of rights on the cube, so I started to browse through the properties for the Cube reader role. In particular, I changed the cube to allow Drillthrough access and then Drillthrough and local cube access, but none of them solved the problem.

After doing some research I found Analysis Services / Cell Level Security - Null Measures and Read Access where Dan Meyers pointed me in the right direction: On the Cell Data tab, we had set (enabled) the checkbox for Enable read permissions for every cube, and Allow reading of cube content field was set to:

[Measures]

According Dan's information, we just disabled Enable read permissions checkbox for every cube and everything worked as expected.

Grant VIEW DEFINITION permission to tables and/or views

SQL Server 2005 still supports all of the fixed server and database roles introduced in SQL Server 2000, along with their default permissions. However, custom database roles, application roles, as well as server logins and database users can be granted (or denied) more granular permissions on a much wider range of objects. Some of the most commonly used permission types present in earlier version of SQL Server, such as EXECUTE, SELECT, or TAKE OWNERSHIP offer new possibilities in their new implementation (since they can be applied on different levels and offer inheritance capabilities). There are also others, newly introduced ones, including, for example:

• CONTROL - functionally equivalent to all permissions granted to the object's owner and inherited by all subentities within its scope,
• ALTER - provides the ability to alter properties of an object. Depending on the scope, you can limit its inheritance to objects of a specific type (for example, its variation in the form ALTER ANY 'object_type' grants permissions to modify every instance of 'object_type' within server or database scope). ALTER TRACE allows running Profiler without membership in SysAdmin fixed server role.
• IMPERSONATE - as mentioned earlier, permits impersonating another user (without requiring SysAdmin or dbo privileges, as was the case in SQL Server 2000),
• and VIEW DEFINITION

According to BOL about VIEW DEFINITION Permission:

The VIEW DEFINITION permission lets a user see the metadata of the securable on which the permission is granted. However, VIEW DEFINITION permission does not confer access to the securable itself. For example, a user that is granted only VIEW DEFINITION permission on a table can see metadata related to the table in the sys.objects catalog view. However, without additional permissions such as SELECT or CONTROL, the user cannot read data from the table.

And now the reasons for this blog entry: If you are using MS Access as your front end for SQL Server 2005, and you have tables with not-nullable columns with default values, as for instance:

CREATE TABLE [dbo].[MyTable] (
  [Id] [int] NOT NULL,
  ... more columns...
  [ColumnName] [int] NOT NULL CONSTRAINT [DF_TMyTable_ColumnName] DEFAULT ((0))
  CONSTRAINT [PK_TMyTable] PRIMARY KEY NONCLUSTERED
  ( [Id] ASC )WITH (PAD_INDEX  = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

your MS Access application will not be aware of the default values for columns in the table and your insertions will fail unless the client manually sets a value for those default values. According, to BOL on Viewing Object Definitions, this is by design:

If the user is not the table owner of myTable and has been granted only SELECT permission on the table, when the user accesses the following catalog views, the definition columns are NULL.

Catalog view name	Transact-SQL definitions for
sys.sql_modules	All triggers in myTable
sys.computed_columns	All computed column in myTable
sys.check_constraints	All CHECK constraints in myTable
sys.default_constraints	All DEFAULT constraints in myTable

If you, your application or your users were used to work with SQL Server 2000 this will appear as a new behaviour, since granting SELECT access to a table in SQL Server 2000 also granted to read the structure of the table itself. Now, in SQL Server 2005, this is a different right and has to be granted explicitly. In fact it is the least privilege: you can only read the structure of the object (securable) but nothing else, you cannot even read data (SELECT). To solve the problem with MS Access not inserting the default values for tables and views, you simply have to grant users the right to VIEW DEFINITION of the tables/views. Keywords: SQL Server 2005, identity, not null, not nullable, default, default value, constraint, view definition, ms access, problem, issue, insert, select, permission.

Account Lockout and Management Tools (Additional Account Info)

This one is quite old and I used to have it already installed on my servers, but now we are moving them to new hardware and I needed to google it to find it again. Account Lockout and Management Tools If you did not know it already, this is a suite of (free) tools, released by Microsoft, that can help you troubleshoot password and account information for your Active Directory users. One of the gems of this suit is AcctInfo.dll that installs an extra tab in Active Directory Users and Computers snap-in. This new tab (called Additional Account Info) shows you:

• Password last set (date & time)
• Password expires (date & time)
• Locked (Yes / No)
• Last-Logon-Timestamp (date & time)
• SID
• GUID
• Last Logon (date & time)
• Last Logoff (date & time)
• Last Bad Logon (date & time)
• Logon Count (integer)
• Bad Password Count (integer)

Extracted from Microsoft documentation:

ALTools.exe includes:

• AcctInfo.dll. Helps isolate and troubleshoot account lockouts and to change a user's password on a domain controller in that user's site. It works by adding new property pages to user objects in the Active Directory Users and Computers Microsoft Management Console (MMC).
• ALockout.dll. On the client computer, helps determine a process or application that is sending wrong credentials.Caution: Do not use this tool on servers that host network applications or services. Also, you should not use ALockout.dll on Exchange servers, because it may prevent the Exchange store from starting.
• ALoInfo.exe. Displays all user account names and the age of their passwords.
• EnableKerbLog.vbs. Used as a startup script, allows Kerberos to log on to all your clients that run Windows 2000 and later.EventCombMT.exe. Gathers specific events from event logs of several different machines to one central location.
• LockoutStatus.exe. Determines all the domain controllers that are involved in a lockout of a user in order to assist in gathering the logs. LockoutStatus.exe uses the NLParse.exe tool to parse Netlogon logs for specific Netlogon return status codes. It directs the output to a comma-separated value (.csv) file that you can sort further, if needed.
• NLParse.exe. Used to extract and display desired entries from the Netlogon log files.

In order to install 'Additional Account Info':

• Copy acctinfo.dll to the %systemroot%\system32 folder
• Register the service and dll running regsvr32 acctinfo.dll
• Close, then open Active Directory Users and Computers.

NOTE 1: If you are using Windows 2003, you should use acctinfo.dll provided with Windows 2003 Resource Kit Tools instead. NOTE 2: If you are using x64 versions of Windows, please note that Windows 2003 Resource Kit Tools are not supported on 64-bit platforms.

VSS & ntbackup errors

We run our backups through scheduled tasks with ntbackup. We do a SystemState backup every day (for us it is enough, maybe in other scenarios more frecuent backups are needed). As part of our dayly checks, we check last run status in the Scheduled Tasks for every server to see if it was successfull (error code 0). Some weeks ago, in order to verify that the backups were restorable, we went to see the actual file (.bkf) and, for our surprise, it was only 2Kb in size. Fortunately, we did not really need to restore the server, it was running fine but... not so fine if the backups were not being done. Why did not we notice it before? Scheduled Task last status said: 0 Ok We went to check the Application Event Log and found:

Type: Error
Source: NTBackup
Category: None
Event ID: 8019
Date: 7/17/2006
Time: 10:16:03 PM
User: N/A
Computer: SERVERNAME
Description: End Operation: Warnings or errors were encountered.
Consult the backup report for more details.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

So we went to check the ntbackup log file, located in %USERPROFILE$\Local settings\Application data\Microsoft\Windows NT\NTBackup\data, and found:

Backup Status
Operation: Backup
Active backup destination: File
Media name: "System State SERVERNAME.bkf created 2006-07-17 at 22:15"

Volume shadow copy creation: Attempt 1.
"MSDEWriter" has reported an error 0x800423f4. This is part of System State.
The backup cannot continue.

Error returned while creating the volume shadow copy: 800423f4
Aborting Backup.

----------------------

The operation did not successfully complete.

----------------------

In spanish:

Estado de la copia de seguridad
Operación: copia de seguridad
Destino de la copia de seguridad activo: Archivo
Nombre del medio: "System State MYSERVER.bkf creado 17/07/2006 a las 22:15"

Creación de instantánea de volumen: Intento 1.
"MSDEWriter" informó acerca de un error 0x800423f4. Esto forma parte del estado del sistema.
La copia de seguridad no puede continuar.

Error devuelto al crear la instantánea de volumen: 800423f4
Anular la copia de seguridad.

----------------------

Operación cancelada.

----------------------

After some research we found that we were experiencing the symptoms exposed in KB828481 - Error 800423f4 appears in the backup log file when you back up a volume by using the Volume Shadow Copy service in Windows Server 2003 with some particularities: Our server is a Windows 2003 Server R2 Standard x64 running as domain controller and with SQL Server 2005 Standard + SP1 installed. Some of our SQL databases have a recovery mode set as Full and should be kept in this mode (changing them into Simple is not an option). However, if we check the server file versions and timestamps for them, and compare them with the data shown in the former KB828481 we found that our server's are more up to date (newer) than those shown in the KB828481:

ntbackup.exe  5.2.3790.1830 (srv03_sp1_rtm.050324-1447)   30/Nov/2005 14:00 
ws03res.dll   5.2.3790.1830 (srv03_sp1_rtm.050324-1447)   30/Nov/2005 14:00 
Wws03res.dll  Not found in our server

Being the files in our server newer than those exposed in KB828481, we understand that the hotfix described there is not suitable for our case, even though we are experiencing the behaviour shown there. After a little more research we found KB913648 - A new Volume Shadow Copy Service update is now available that fixes various Volume Shadow Copy Service problems in Windows Server 2003. In this case the document is newer (Juy 26, 2006) but having a look into the problems fixed by this hotfix suggests us that this is not our case either (too complex things for our little simple configuration/server). Besides, the server had been doing the backups for months (confirmed) before we noticed that it was not doing them anymore. Just for your information, when we run vssadmin list writers in a command prompt, the process seemed to wait indefinitely and, after 30 minutes, we press CTRL+C:

C:\WINDOWS\system32>vssadmin list writers
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001 Microsoft Corp.

Waiting for responses.
These may be delayed if a shadow copy is being prepared.

^C
C:\WINDOWS\system32>

The server experiencing the problem has not a very high workload, not from the fileserver point of view (litle company with 25 employees), nor from the SQL Server's transactional point of view (somewhat near 1000 transactions per hour). Solution: Finally, the steps that solved the problem were:

cd %windir%/system32
net stop vss
regsvr32 /s ole32.dll
regsvr32 /s vss_ps.dll
vssvc /Register
regsvr32 /s /i swprv.dll
regsvr32 /s /i eventcls.dll
regsvr32 /s es.dll
regsvr32 /s stdprov.dll
regsvr32 /s vssui.dll
regsvr32 /s msxml.dll
regsvr32 /s msxml3.dll
regsvr32 /s msxml4.dll

And a reboot of the server. Links:

• KB828481 - Error 800423f4 appears in the backup log file when you back up a volume by using the Volume Shadow Copy service in Windows Server 2003
>
• KB912414 - Error message when you use the Volume Shadow Copy Service (VSS) to back up SQL Server 2000 database files or SQL Server 2000 Desktop Engine (MSDE) database files: "'MSDEWriter' has reported an error 0x800423f4"
• Lukesh' post at microsoft.public.windows.server.general