When you integrate a site onto its final server – things with windows get hairy. Here are some notes to get out of trouble
- seeing a 401 for anonymous user? Are your permissions for IUSR set to read, write, execute (ref)? This is for anonymous user. For a dynamic user, then you have to add permissions for NetworkService (see small note in this reference) (6.1 – or see this article for 7.5). For this, I had an account called (built in account: ApplicationPoolIdentity – this not correct – I will keep digging)
- you might also require the group IIS_IUSRS to have read, write, execute. It depends on your version of IIS (see this link – this is succinct)
- ensure BOTH the user accessing the page and the AppPoolIdentity user BOTH have NTFS permissions set to the directory and subsequent web pages (reference)
- Do NOT set Everyone to Full – but it is a good test to see if the above will work.
- I used the Login security stuff that came with the default forms. Now the server I was going to already had SQLSERVER pre-installed (VS2012 Express)
- The aspx debug version worked great – no issues … untilI published that part to the server (everything else worked)
- First, FTP will not copy over your App_Data folder stuff. It is in the fine print when you set up your publishing scheme. Copy those over using a manual method (ironically FTP)
- The default website did NOT have a DefaultConnection String so I added it
- <add name=”DefaultConnection” providerName=”System.Data.SqlClient” connectionString=”Data Source=1KX8JZ;Initial Catalog=aspnet4;AttachDBFilename=|DataDirectory|\aspnet.mdf; User Id=usernameaccount; password=xxxxxx” />
- HOWEVER you will see it has a username and password that I then have to add into SQL Server – again a pain and more fiddling but it works (I can’t find the web article that led mere here – sorry – it is on Stack Overflow). This guy did get it to work
- Then I added this user ‘usernameaccount’ to the SQL Database (using Management Studio) – note that I could NOT have a database pre-created called aspnet4. Why? Because it uses the file in the connection string under the App_Data directory called aspnet.mdf and fakes it in SQL Server as aspnet3
- this username ‘usernameaccount’ had to have the following roles added for the master database
- server roles: dbcreator
- database role membership for master: db_securityadmin
- database roles for the aspnet4? leave this alone – it configures itself
- THEN I had to have full access to the App_Data directory for the user NT SERVICE\MSSQLSERVER so that SQL could marry the real dB with the virtualized one (aspnet4).
- you can find this user by running services.msc (Start->Control Panel->Administrator Tools->Services->SQL Server (XXXX)->Properties->Logon Tab
- What a pain! This took me only 5 hours to figure out, hack and clean things up (broke a few things again- learned more – wrote it here). I hope it helps someone.
Because everything in release vs. test was different, I had to use the Web.release.config transform file to put custom connection strings for the release server. I had to change my publish to “Release” under properties.
Once I require a password reset – one needs to configure an email server and few other options. This is all summed up nice in this article. http://www.codeproject.com/Articles/15693/Password-Recovery is also good but incomplete (needs some work) All I did was add an smtp server and added the passwordFormat=”Hashed” attribute in Web.config to the <membership><providers> xml node.
- Other Links
- rolling out own WSAT: http://aspnet.4guysfromrolla.com/articles/052307-1.aspx