September 7, 2007 at 12:41 pm
Problem Description:
SSIS packages using package configuration in order to be
mobile from machine to machine.
SSIS package runs correctly when running as an ADMIN using
the package configuration thru the SQL Agent scheduler.
SSIS configuration is kept in a SQL SERVER table.
SQL SERVER SERVICE AND SQL AGENT Services running as a domain
user with proper permissions on local box.
Want to use least privilages set so Local account set up for
proxy use.
Proxy account granted rights to the SSIS subsystem.
Package connects to AS400 and pull data into SQL SERVER. Package does not use cmd_shell.
SSIS packages stored on OS file system.
SSIS job set up in the SQL AGENT JOB scheduler with the owner
of the job set to the proxy account and the job step runs as
the proxy account.
Running the job results in the following errors:
Date 9/7/2007 8:37:24 AM
Log Job History (CMDDBSmallTables)
Step ID 1
Server ASERVER
Job Name AJobName
Step Name ASTEP
Duration 00:00:06
Sql Severity 0
Sql Message ID 0
Operator Emailed
Operator Net sent
Operator Paged
Retries Attempted 0
Message
Executed as user: aserver\auser. ...00 for 32-bit Copyright
(C) Microsoft Corp 1984-2005. All rights reserved.
Started: 8:37:25 AM Error: 2007-09-07 08:37:30.38
Code: 0xC001403D Source: Description: The log
provider type "DTS.LogProviderEventLog.1" specified for log
provider "SSIS log provider for Windows Event Log" is not
recognized as a valid log provider type. This error occurs
when an attempt is made to create a log provider for unknown
log provider type. Verify the spelling in the log provider
type name. End Error Error: 2007-09-07 08:37:30.38
Code: 0xC0010018 Source: Description: Error
loading value "<DTS:LogProvider
xmlnsTS="roperty'>http://www.microsoft.com/SqlServer/Dts"><DTSroperty
DTS:Name="ConfigString"></DTSroperty><DTSroperty
DTS:Name="DelayValidation">0</DTSroperty><DTSroperty
DTS:Name="ObjectName">
</DTSrop" from node "DTS:LogProvider". End Error
Could... The package could not be lo... The step failed.
Assumptions:
I beleve the package configuration to be complete, since
the above package runs correctly thru the scheduler using
an adminstrative ID with the package configuration. The package
configuration has no mention of the "SSSIS log provider for Windows Event Log".
Therefore, I believe the text of the error message is not accurate for the
error that I am actually receiving.
Statement:
If the above asumptions are not correct, I am not sure how to specify the
"SSSIS log provider for Windows Event Log" in the Configuration table.
Question:
Are my assumptions correct?
Has anyone else see this issue?
Am I missing that is causing the proxy account not to execute the job correctly?
Is there any way to work around this error?
June 8, 2011 at 4:55 am
Hi
I had a similar problem recently. It is most likely because although your AD user has rights on the server, it does NOT have rights to write to the system log you're using. I'll assume you're using the Application log in this reply.
The fix is the same whether you're using Win 2K3, Win Vista, Win 7 or Win 2K8, but the method of application differs a little. Basically you need to add some information to the registry, but in Vista, 7 and 2K8 there is a little system utility you can use to make life a little easier. The registry key in question is:
HKLM\System\CurrentControlSet\Services\Eventlog\Application\CustomSD
Which may or may not exist to start with. Let's assume it does NOT exist and we will start with Win 2K3. As with all registry operations, if you are directly editing be sure you know what you are doing before you start and take a backup. If you are not sure then this method is not for you!! Don't despair, there are some alternatives which I will tewll you about after I explain the manual method.
You will need to add the key and make the type REG_SZ (a string). The key contains a chunk of SDDL (Security Definition Descriptor Language) which is impenetrable at the best of times. The default value for the Application log is:
O:BAG:SYD:(D;; 0xf0007;;;AN)(D;; 0xf0007;;;BG)(A;; 0xf0007;;;SY)(A;; 0x5;;;BA)(A;; 0x7;;;SO)(A;; 0x3;;;IU)(A;; 0x2;;;BA)(A;; 0x2;;;LS)(A;; 0x2;;;NS)
So you will need to start with this. To let your SSIS service account write to this log you will need to append the following to the above default:
(A;;0×3;;;{SID})
Where you replace {SID} with the SID of the service account. That will limit write permission to the Application log to that account only. If you cannot obtain the SID of the account (which can be a nuisance) you can change {SID} to AU which grants write access to the Authenticated Users domain group, thus:
(A;;0×3;;;AU)
If the CustomSD key already exists then you only need append the (A;;0×3;;;{SID})
part to the existing key.
OK, so you're not keen on editing the registry yourself? No problem - this can be achieved using the server's Local Group Policy. The manual method described above and the Local Policy method (as well as one other) are described here:
http://support.microsoft.com/kb/323076
Now let's move to later OS platforms where there is a handy tool called wevutil that means you don't have to directly edit the registry. There is an excellent and verbose explanation available here:
http://jpadda.wordpress.com/2010/08/08/event-log-write-permissions/[/url]
I will reproduce it here in case this link ever dies:
Access to Write to Event log
Open Cmd prompt as admin.
Type: C:\>wevtutil gl application > C:\temp\out.txt
This outputs the security credentials for the application event log to the given text file.
Open the generated C:\temp\out.txt file in Notepad
It looks a little bit like this:
name: application
enabled: true
type: Admin
owningPublisher:
isolation: Application
channelAccess:
O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0×7;;;BA)(A;;0×7;;;SO)(A;;0×3;;;IU)(A;;0×3;;;SU)(A;;0×3;;;S-1-5-3)(A;;0×3;;;S-1-5-33)(A;;0×1;;;S-1-5-32-573)
logging:
logFileName: %SystemRoot%\System32\Winevt\Logs\application.evtx
retention: false
autoBackup: false
maxSize: 20971520
publishing:
The line you’re interested in is the “channelAccess”. (The wonderful Windows SDDL – Security Descriptor Definition Language).
You need to add (append) the following to the end of the line:
(A;;0×3;;;AU)
- This gives write/read access (the “0×3” bit ) to Authenticated Users (AU).
You then need to apply the updated setting…
C:\>wevtutil sl Application /ca:
O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0×7;;;BA)(A;;0×7;;;SO)(A;;0×3;;;IU)(A;;0×3;;;SU)(A;;0×3;;;S-1-5-3)(A;;0×3;;;S-1-5-33)(A;;0×1;;;S-1-5-32-573)(A;;0×3;;;AU)
Done.
You can check the change by:
C:\>wevtutil gl application > C:\temp\updatedout.txt
And you’ll see the change in the channelAccess line.
The more eagle eyed amongst you (and you’d need to be eagle eyed to spot this) will notice that the registry location:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application
now has an additional keyCustomSD
with the updated channelAccess key. This key only appears if the default configuration is changed, i.e. as I have done by granting Authenticated Users write access.Important Info: Only applies cos the application user is not the NetworkService, but a domain user. The NetworkService user is already part of the approved list, so you won’t need to apply these steps.
Further Reading:
If you would like to prevent authenticated users from writing to the event log, and would prefer to lock down security further, you can follow the process above, but rather than giving access to all authenticated users, you can grant access to specific users by adding their SID (security ID) to the channel access list instead. VBScript to find SID for a user.
I hope this helps. You may need the help of a domain admin for some of this, depending on how your network is configured and your own rights.
Incidentally, where you see the unhappy smiley, that is supposed to be a colon : followed by an opening parentheses ( but I can't figure out how to stop the damn smiley appearing. You will see it without the smiley in the links I've provided.
June 8, 2011 at 5:05 am
Word of warning:
I've just done this as I typed it out on a Win 2K3 server and it didn't work at first. I checked the reg key very carefully and it appeared that the 0x3 looked different, font-wise, from existing parts of the key. I copied the 0x3 from another section, pasted it in and hey presto it worked. SDDL is not user friendly!!
Steve
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply