Sharepoint 2010 DeleteExpiredSessions job is registered for the database - asp.net

I am running SharePoint 2010. I keep getting "Expired sessions are not being deleted from the ASP.NET Session State database." warnings.
I connect to the server that hosts the ASP.NET Session State database, I start the SQL Server Agent service, and I confirm that a DeleteExpiredSessions job is registered for the database. I execute the stored procedure and a couple minutes later the warning is gone.
I come back the next day and I have the warning again. My question is there must be a way to automate this execution right? Either directly in SQL Server Management Studio or SharePoint Central Administration. I can't seem to find out how though.

You can re-create the "State Service Delete Expired Sessions" job definition by disable and re-enable the ASP.Net State Service via powershell, also you should verify that your account has the appropriate permissions in order to allow it to create SQL Agent jobs.
Disable-SPSessionStateService
Enable-SPSessionStateService –DefaultProvision
Here you can read a little more about this fix.

Related

SSISDB ASP.NET "Login failed for user 'DOMAIN\PCNAME$'"

I am using Microsoft.SqlServer.Management.IntegrationServices in an ASP.NET web form to access an SSIS project in SSISDB. Testing locally on my own PC I am able to access the package from the test server and it runs fine.
My issue comes up when I try to run the site from the test server. The same test server hosts the site with IIS 7 and hosts the Sql Server database which stores the package with Integration Services. So like I said, the package is hosted on the server and when I run the site locally on my PC, all works fine.
When I run the site on test and try to access the package I get:
System.Data.SqlClient.SqlException (0x80131904): Login failed for user '[DOMAIN]\[PCNAME]$'.
I am using integrated security in my connection string:
SqlConnection connection = new SqlConnection(#"Data Source=[Test_Server];Initial Catalog=master;Integrated Security=True;");
IntegrationServices integrationServices = new IntegrationServices(connection);
My error comes up here when trying to connect.
I've tried adding '[DOMAIN]\[PCNAME]$' as a Sql login using Windows authentication with every permission I can think of. User mapping for database SSISDB has accessadmin, datareader, datawriter, owner, public, and ssis admin. I know not all of these should be needed, but I'm trying everything.
I went to SSISDB under databases, and gave the login permission to Connect, Execute, and Select.
Under Integration Services Catalogs I gave my folder, under SSISDB catalog, permission for the my Windows User ('[DOMAIN]\[PCNAME]$') login to Read, Execute Objects, and Read Objects.
I gave the SSISDataTransfer project permission for the Windows User to Read, Modify, and Execute.
I'm out of ideas and figure it's probably some IIS issue. It has Windows Authentication installed and set.
Anyone have any ideas? I've found posts about how to get the code to work, but nothing on connection specifics. Thanks!
i have had similar problem recently and i have worked with SSIS packages being used with web applications too. in my opinion you should use a custom user account to be used as your app pool account. and you will have to add this account to your database server. when running an app pool as local system or network service, the account being used for connection to a remote database server will be "DomainName\MachineName$" which will be different for every machine which tries to connect to your sql server. so instead of adding all these user names in sql, you will be better off using a custom user account.
Secondly looks like your web application does not run on the same machine as your sql server which i think will not work because you can invoke SSIS package from the same server only.
Another thing to try is to add a credential to sql server - in Security - Credentials in SQL Server management studio. This credential would be the authenitcated user that you are running it successfully under. Then in your SSIS package, in SQL Server agent, go into the job step and in the "Run As"drop down, select the new credential for your user that you created.

Granting sql server database access to IIS APPPOOL\DefaultAppPool

I have an ASP NET APP that's trying to access a sql server database, when I run it, I get an error saying
"Login Failed for user IIS APPPOOL\DefaultAppPool"
Searching the web I found that I should grant access to this user, so I executed the following script:
grant execute on schema :: dbo to [IIS APPPOOL\DefaultAppPool]
It executed succesfully as a script for my database, but I still get the "Login Failed" error.
What's missing?
Check the user your DefaultAppPool is using to connect.
On your IIS manager check DefaultAppPool advanced properties and look for Identity. You need to give it a user with enough privileges, depending on what your site is going to do.
I usually create different AppPools for different sites depending on what they will do, for example, if your app will write documents to a folder on your server, the user of the AppPool will need writing access to that folder.
Also is not a good idea to use an administrator user, as it could lead to potential security breaches. However it could be a good way to check if your problem comes from there.
I think I already know what it is. When I upgraded SQL Server Express, it installed a new server .\SQLEXPRESS (because I used "new sql instance"), remote connections where configured in this server and not LocalDB, my database was still in LocalDB. But now I get other error, maybe related to WCF Data Services...

Operating system error code 5(Access is denied.) when bulk insert

I have an ASP.NET application on Server A and a SQL Server on Server B.
When running the appliction it calls a stored procedure. This procedure try to bulk insert from a file from a shared folder on Server A, but the following error occured:
Cannot bulk load because the file "\serverA_address\sharedFolder\test.txt" could not be opened. Operating system error code 5(Access is denied.).
The strange is that when I execute the bulk insert from the sql management studio directly, it runs without any exeptions.
Another observation: if I change the shared folder address to a local folder where the sql server runs (Server B) without shareing, no access denied error...
I tried to set bulkadmin permission to all the users, including the technical users: sql_serviceusr who runs the sql service, another technical user who runs the application and make the call to sql server and to the user who logged in to the application. All users are domain accounts and all servers using Kerberos authentication.
Server A: Windows Server 2008R2
Server B: Windows Server 2008R2, SQL Server 2008R2
Appreciate any help or guidance.
You are doing a double hop, so you need to enable Kerberos delegation.
You could create a connect account and use SQL authentication.
In my experience, getting our network folks to properly set up Kerberos is like pulling teeth. We had it working for one glorious week once and then it suddenly stopped working. It just wasn't worth the hassle after that.
This might not be the exact answer you're looking for, but could be an interim solution for you.
By your description of the error, I assume the problem is in sharing the folder.
When sharing a folder, you should give access to the user who will be accessing the folder from remote computer in two places in folder's properties: under the Share tab and under Security tab.
Did you give access in both of them?

what does 'run the ASP.NET worker process with dbo privileges' mean?

I am having issues implementing SqlSiteMapProvider using the Wicked Code article. I am using VB.NET and SQL Server 2008 - and the OnSiteMapChanged event is not firing (the SqlDepdencyCache just seems to simply be not working at all).
The article states "You also need to run the ASP.NET worker process with dbo privileges for SQL Server 2005 cache dependencies to work automatically.)"
I don't understand what this means. I know what the ASPNET user account is and that it runs aspnet_wp.exe which is basically the ASP.NET run time as I understand it. I know what DBO privs are on SQL. But my SQL and web servers are on different machines, and ASPNET is not a domain account. And it seems crazy to make it one to try to simply get the SqlDepdencyCache to work, and I have trouble believing everyone is doing this?
Anyone have any clue what I'm missing here?
Thanks very much
EDIT: I FOUND MY ISSUE!!! SET NOCOUNT ON INSIDE MY STORED PROC WAS CAUSING IT!! BEWARE AS THIS IS NOWHERE IN THE MSDN DOCUMENTATION!!!!
Your worker process identity needs to be changed to either a domain user OR a user with a matching username/password on both the web and database servers. The SQL Server would also need Windows authentication (or Mixed authentication) enabled.
Under IIS 5 (Windows XP/2000), you need to modify the ASP.NET Process Identity in the machine.config file.
Under IIS 6 / 7 (Windows Vista/7/2003/2008/R2) you should just be able to modify the Application Pool identity. If this doesn't work, enable <identity impersonate="true" /> in your web.config.
SqlDependencyCache uses SqlDependency and SqlDependency deploys at runtime a set of services, queues and stored procedures in your database as part of its infrastructure. You can read this article on more details what really happens The Mysterious Notification.
When you create your site map provider, you provide a connection string. This connection string specifies either a SQL login and password, or it specifies that SSPI (or Trusted, or Integrated) Authentication should be used. When a user and password are provided then this user is used to log in into your application database (the ASP database). When SSPI is used then the conenction is made using the ASP thread identity, which is either the app pool identity or the impersonated user identity. Whichever login ends up being used, this login must have the priviledges necessary to deploy the SqlDependency infrastructure (create a queue, create a service, create a stored procedure). The simplest way is to simply make this login's user in the database member of the db_owner role (which is the correct wording for what the article calls 'dbo priviledges').
So depending on yoru connection string, your app pool identity and your impersonation settings, the database user that corresponds to the login used by the map provider must be added to the db_owner role. I can't tell what you need to do, because it all depends on the variable factors enumerated above.

Understanding performance hit of an application role in SQL with ASN.NET

I use MS SQL Server 2005 application roles in an application. I execute the sp_setapprole to start the SPs role and to finish sp_unsetapprole.
"connection pooling doesn't work" with application pooling, and there is no way to react on connection "disconnect event" (execute sp_unsetapprole just before disconnection).
I decide to call sp_setapprole at the start of all my SPs and call sp_unsetapprole at the end of all SPs.
Have you used SQL application roles? What are your XPs? What about performance hits?
I've rolled my own "approle" in the past, it's not too hard. Create a database role for each type of user (manager, casher, clerk, whatever). Create a database user with the group name (manager_user, casher_user, clerk_user etc). Create accounts for your real users and put them in the database roles. Validate your asp.net users by logging them into the database (open & close a connection), a lookup table or best if you use windows authentication and just get their user name from IIS. Check their membership in a database role but log in to the database using role_user. You can secure the database objects via the role_user, the users don't login and don't have access to any sql objects and you get connection pooling.
I have not used app roles before, but from what I know about the perf hit is that after setting the application role there is no way to revert to the prev. security context. Thus the connection cannot be reused in pooling. This alone is a huge perf. hit that forces you to think twice about using app roles.
However, the docs say that starting from SQL Server 2005 there is a way to remember the original security context in a kind of cookie returned from sp_setapprole and after that use sp_unsetapprole to revert back to it. So the pooling should work again. If I were you, I would compare the perf. with a couple of simple statements/sprocs.
Any reason you don't use the standard ASP.NET membership API on the application level instead of app roles?

Resources