March 19, 2013 at 4:26 am
OS: Windows 2012, standard, 64-bit
SQL: 2012 + SP1 + CU2 = 11.0.3339
We recently decided to "break apart" our BI environment. We used to have everything on one box, DB Engine, SSIS, SSAS & SSRS. Everything has been running fine, but we now have other projects using these services, so we decided to break them apart into their own boxes.
We now have DB Engine on one Server, SSIS & SSRS on another server and SSAS on yet another server, so we now have three boxes that replaced one box. All are Windows 2012, standard, 64-bit with SQL Server 2012 + SP1 + CU2.
Since some of our SSIS packages have to access external resources, we used a domain account for it's service account. The DB Engine and SSAS box are using the default service accounts when installed. I can execute the packages fine on the SSIS server, I can even execute them via SQL Agent jobs on the SSIS box (we did install a default instance of SQL on the SSIS box), however when I try to execute a package from my laptop, it fails with the ugly "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'". I immediately double checked my SPNs and they all looked correct for the SSIS server and the service account we are using (and we had no duplicates). I also double checked the User Rights Assignment in the Local policy editor and all the correct Rights have been assigned (Log on as a service, Bypass traverse checking, Impersonate a client after authentication).
I'm stumped here. Anybody have anything else I can check or that I have overlooked?
Thanks
-A.
August 13, 2013 at 6:16 pm
Have you figured this one out?
Thanks,
--ivan
August 14, 2013 at 9:20 am
Ivan.Huter (8/13/2013)
Have you figured this one out?Thanks,
--ivan
Whatever method the OP was using to try to execute an SSIS package on a remote server from a laptop was probably attempting to log in to the server hosting the SSIS instance with a local account on the laptop, quite likely the NetworkService account. If so, the server was rejecting the login attempt because it didn't come from a domain account or a recognized local account (local to the server, that is), thus its designation as an anonymous login attempt. The OP probably needs to reconfigure the process to use a domain account with appropriate permissions to log in to the remote server.
Jason Wolfkill
April 22, 2014 at 12:09 pm
Are you guys sure this doesn't have anything to do with the DCOM configuration? I'm running into the same issue (all our stuff is running under domain accounts). In pre-Win2012, there was a DCOM setup for the MsDtsServer100 DCOM component. I don't see that component in in Win2012.
Anyway, I was searching for where that component when or what changed with SQL 2012 and ran across this post.
Greg
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply