Clients updating against an SMB Internal LiveUpdate Server may occasionally fail to update

Products

• Endpoint Protection

Issue/Introduction

Clients updating against an SMB Internal LiveUpdate Server (LiveUpdate Administrator 2.x, for example) may occasionally fail to update and log the following error: HR 0x802A0033 DECODE: E_CANT_CREATE_FILE

Symptoms
Clients configured to run LiveUpdate against an Internal LiveUpdate Server configured to distribute the definitions via an SMB Share may sporadically fail to update. The LiveUpdate log will include entries similar to the following:

22/10/2009, 09:21:05 GMT -> Progress Update: DOWNLOAD_FILE_START: URL: "1256191148jtun_nav2k8en91020051.m25", Estimated Size: 526536, Destination Folder: "D:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\Downloads"

22/10/2009, 09:21:06 GMT -> Progress Update: DOWNLOAD_FILE_FINISH: - NOTE - URL: "1256191148jtun_nav2k8en91020051.m25", Full Download Path: "D:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\Downloads\1256191148jtun_nav2k8en91020051.m25" HR: 0x802A0033
22/10/2009, 09:21:06 GMT -> HR 0x802A0033 DECODE: E_CANT_CREATE_FILE

Note that even if the LiveUpdate client logs this error against the incremental update (*.m25), it will typically fall back to the full def set. However, if the SMB server is very busy, this file may also record a similar access violation.

Cause

This problem only occurs if two or more clients access the same file at exactly the same time. All clients need be on the same AV signature version when they try to get the newest ones as this would lead to the download of the same incremental updates file *.m25 residing on the update share. This is a limitation imposed by how the SMB/CIFS (Windows File Sharing) protocol is implemented.. When reading or writing a file via SMB network share, the remote system is granted an exclusive lock on the file while it is being downloaded/uploaded. If a second request for the same file is encountered before the first read/write task is completed, it will be signalled that a permissions conflict has occurred. This causes LiveUpdate to record the error HR 0x802A0033 DECODE: E_CANT_CREATE_FILE.

Resolution

It is rare for this type of access collision to occur in all but the largest of environments which will see the highest load levels, and are most likely to see multiple simultaneous read/copy requests for the same file via LiveUpdate. However, neither HTTP or FTP display this type of limitation (both of these access protocols do support multiple simultaneous file read requests), and as such our principle recommendation would be for our larger customers to distribute the AV Definitions via FTP or HTTP.

If it is necessary to distribute the definitions via SMB Shares, then it may be necessary to schedule multiple LiveUpdate sessions or implement "Continuous LiveUpdate" to ensure that the client will re-try the connection if it is initially refused access.

Any changes to the way in which LiveUpdate handles the SMB Access Denied messages should be raised in the Symantec Connect Ideas forum, as this is the most appropriate location for Product Enhancement Requests.


References
CreateFile API
- http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx

Optimizing Applications for Remote File Access Over WAN
- http://download.microsoft.com/download/f/2/1/f2146213-4ac0-4c50-b69a-12428ff0b077/Optimizing_Applications_for_Remote_File_Access_Over_WAN.pptx


Technical Information
Operating system (File System) access to any file is via the CreateFile API. There are a variety of acccess levels and access methods supported by this API, and the type of access granted will be dependent upon any pre-existing access operations in place, in combination with the ShareMode and DesiredAccess flags.

When an application such as IIS attempts to access a local file for read purposes, it uses the CreateFile "GENERIC_READ" (DesiredAccess) and "FILE_SHARE_READ" (Sharemode). This means that while IIS is accessing the file (and providing it to the user), a separate process (another IIS worker thread, or some other access) can request access and gain similar permissions. This means that IIS can "serve" the same file to multiple simultaneous connections.

However, when a remote computer attempts to access a shared file via SMB, this communication is mediated by the application requesting access to the file in its local OS. The local OS verifies whether the file already exists in its local SMB cache. If the file is not already cached, it then initiates a connection to the remote server to request the file. the server verifies if the file is already cached for that particular session. if it is not, it then attaches to the file via the CreateFile API. This SMB connection is always established as "GENERIC_READ | GENERIC_WRITE" (DesiredAccess) with a "FILE_SHARE_READ" ShareMode. Once the file has been copied into the SMB cache for this connection, The Server will close the "CreateFile" access to the requested file, return the copy to the requesting client, and (if requested) maintain an OpLock on the original file. However, it does not maintain a "CreateFile" connection to the file.

This means that while the SMB connection actually copies the file into the SMB cache on the server, an application such as IIS running locally on the server could still simultaneously load the file, but only one SMB connection to the same file can be served at any time. If a second access attempt via SMB is attempted while the initial connection is still active, the OS on the server will respond with an "access denied" message to the remote (requester) system.

When this "access Denied" message is relayed to the SMB requester (the client), it is communicated up to the requesting Application. LiveUpdate logs this error state as HR0x802A0033 (E_CANT_CREATE_FILE), and moves on to the next file.

Note that the changes to the SMB networking protocol in Windows Vista and Windows 2008 modify the efficiencies around how these file acceses are managed, but overall, the limitations remain constant - LiveUpdate will return an error if another client is downloading the file at the exact moment that client attempts to request the file.