Problem:
No access to internal sites after new Instance of SQL was installed on MS SQL Server
Description:
I've got a WSS 3.0 installed on the W2K3 Sever.
Originally, there was only one Instance of MS SQL (MSDE) for Backupexec (bkupexec). Later, we installed WSS 3.0 and instead of installing the new instance of SQL we installed on the same instance (bkupexec). So, at some point all the DBs from Backupexec and DBs from WSS were all together within the same SQL instance.
After we noticed this we wanted to split those two into two separate instances: bcupexec and sharepoint. First, I have done a backup of all DBs within backupexec instance. Then, I installed new SQL Instance and called it Sharepoint and tried to restore all WSS DBs into the new SQL instance. Once that was done I check references in IIS so Content and Config would point into the new instance. But since then no go.
I can access Admin site from within IIS and from the browser. I cannot access any internal WSS sites. It asks for the authentication. All I am using is Windows authentication. Account is in AD.
As I am new to WSS I will be greateful for all suggestions and possible fixes.
If you have changed where the content DB's are located for your site collections you will need to detach and re-attach them using the SharePoint Central Admin.
Navigate to Application Management and switch to the application you're concerned about. Click "Content Databases" under the heading SharePoint Web Application Management. From here you can click "Remove content databse" and hit OK.
This will not remove the physical database from SQL, it will simply disassociate the database with that web application. You can then Add a content database from within the manage content databases screen and type the name of the database you wish to associate the application with.
If the permissions issues persist, ensure that Anonymous access is enabled for the application and that appropriate service account permissions are enabled for the DB's from within SQL and SharePoint.
Not sure this will help, but give this a try...
In central administration make sure you check on the site collection administrator for your site collections and make sure you are using that user.
In IIS Manager, check to make sure that user has access to the IIS web site.
Related
I'm looking at using SQL LocalDB as the client side database which will replace the current SQL CE 3.5 database inside an in-house application developed in .net 4.
I've come across a problem that I'm not sure how to get around and that's with security setup of the LocalDB instance.
If I setup a script inside .net to create a private LocalDB instance, e.g. (localdb)\T1, then create a new database inside that instance plus add a SQL user account + password (non domain account), how do I stop the local windows users (like my own AD account) with admin level privileges from accessing the 'T1' instance + database using SSMS?
I could see a scenario playing out where we deploy the application, then we have some IT savvy user who goes snooping around and decides to install SSMS and connect to (localdb)\T1 with their windows account, which would give him/her full access to the database, which is exactly what I'm trying to stop from happening.
Some of our staff work remotely with no connection to a domain so we give them local admin rights to their pc so they can install software, so even if I could block their assigned windows login name, there would be nothing stopping them from setting up a new local admin account and logging in with that, opening SSMS then accessing the database.
Any pointers on this would be greatly appreciated!
In fact, it shouldn't be so hard. Install SQL Server on client machine using local admin account. To make you life easier, use Mixed Authentication.
After you have your instance installed, local admin account should have sysadmin server role assigned (that's normal security settings). Now, use the following:
Create new SQL Server user and assign sysadmin server role to that account. Close SSMS and log-in using new credentials. Or simply use sa account (not so good practice but in this case it's OK).
Go to "Security - Logins" and remove sysadmin role from local admin. Also, check in user mappings and take all rights "away" from local admin.
As a test, try to log-in as local admin, I guess you won't be able to log-in into server because there is no "home" database for that user. But even if you can log-in, it has only "public" role.
It's up to you to install your database and secure it - assign permission to user of your choice.
Regarding you fear that local admin can install MSSQL again: he/she can install it, but it would be another instance. That instance knows nothing about users in your instance so you should be safe.
You can also consider usage of application roles in SQL server.
I have a sharepoint 2010 portal with some dashboards and reports. No I have a permission problem, because I cannot view these reports.
I would like to have a look in Reporting Services Configuration Manager, but I cannot connect to the server where sharepoint and SQL server is installed. I enter the server name and press on find. It gives me the following error:
Unable to connect to the Report Server MYSERVERNAME.
By the way, I try to fix this problem:
AccessDeniedException: The permissions granted to user
'Mydomain\MyUserAccount' are insufficient for performing this
operation.
First off, you probably want to be using SharePoint Central Administration, not RS Configuration Manager. Also, RS Configuration Manager isn't where you'd manage access to report objects.
That said:
Try remoting into the host machine and running the tool locally on the server.
Ensure the proper ports are open for you to be connecting remotely (and that they SHOULD be open - there are very valid security reasons to block them)
Are you 100% certain you're connecting to the right address? Is it possible the SSRS service itself is on a different machine than the Sharepoint service and the SQL server?
Is there any way so IIS could connect to LocalDB without using the NT SERVICE\NETWORK SERVICE user account.
This account has not suitable permissions. I'm looking use some other default account or is there some way that I can use the NETWORK SERVICE account without changing permissions?
You should use Shared Instances feature of LocalDB. These two posts on Using LocalDB with Full IIS should give you more information. Especially the second part seems relevant, but the first one contains some context as well.
(note: the original links are no longer available, using archive.org instead)
Part 1: User Profile
Part 2: Instance Ownership
Original (non-working as of March 2019) links:
Part 1: User Profile
Part 2: Instance Ownership
In case the links disappear again, I am copy-pasting solutions from the article for easier access:
Post 1:
The problem we're facing is that the user profile needs to be loaded. That shouldn't be hard since each IIS Application Pool has an option called Load User Profile that can be found in Advanced Settings section. Unfortunately things got slightly more complicated in Service Pack 1 for Windows 7. As described in KB 2547655 enabling loadUserProfile is not enough to fully load user profile, we also need to enable setProfileEnvironment. This requires editing applicationHost.config file which is usually located in C:\Windows\System32\inetsrv\config. Following the instructions from KB 2547655 we should enable both flags for Application Pool ASP.NET v4.0, like this:
<add name="ASP.NET v4.0" autoStart="true" managedRuntimeVersion="v4.0" managedPipelineMode="Integrated">
<processModel identityType="ApplicationPoolIdentity" loadUserProfile="true" setProfileEnvironment="true" />
</add>
Having completed that we restart the Application Pool to make sure the new settings are applied and run our Web Application again.
Note from my side: Just find "applicationPools" tag in that applicationHost file and update those two variables to true, so it looks like this:
<processModel identityType="ApplicationPoolIdentity" loadUserProfile="true" setProfileEnvironment="true" />
That's it, save the file and restart IIS pool.
Post 2:
The Problem of the Private Instance
As we can see we are facing the following error:
System.Data.SqlClient.SqlException: Cannot open database "OldFashionedDB" requested by the login. The login failed.
Login failed for user 'IIS APPPOOL\ASP.NET v4.0'.
This time the error is quite clear. LocalDB was started and the Web Application was able to connect to it, but the connection was then terminated due to login failure. The ApplicationPoolIdentity account for the IIS application pool (in this case IIS APPPOOL\ASP.NET v4.0) couldn't login to LocalDB instance because the database specified in the connection string (OldFashionedDB) wasn't found. How odd, since connecting from Visual Studio with the same connection string succeeds!
How is it possible that Visual Studio connects to LocalDB just fine, while the connection from Web Application fails? In both cases the connection string is the following:
Data Source=(localdb)\v11.0;Initial Catalog=OldFashionedDB;Integrated Security=True
The answer is that there are two different LocalDB instances here. Unlike SQL Server Express instances, which are running as Windows services, LocalDB instances are running as user processes. When different Windows users are connecting to LocalDB, they will end up with different LocalDB processes started for each of them. When we connect to (localdb)\v11.0 from Visual Studio, a LocalDB instance is started for us and runs as our Windows account. But when Web Application, running in IIS as ApplicationPoolIdentity, is connecting to LocalDB, another LocalDB instance is started for it and is running as ApplicationPoolIdentity! In effect, even though both Visual Studio and Web Application are using the same LocalDB connection string, they are connecting to different LocalDB instances. Obviously the database created from Visual Studio on our LocalDB instance will not be available in Web Application's LocalDB instance.
A good analogy to this is My Documents folder in Windows. Say we open Visual Studio and create a file in our My Documents folder. Then we login to the same machine as a different user and go to My Documents folder again. We won't find the file there as My Documents of the second user and our My Documents are two different folders. Similarly LocalDB instances (localdb)\v11.0 owned by two different users are two different processes with two different sets of databases.
This is also the reason the Web Application was able to connect to LocalDB from IIS Express. Just like LocalDB, IIS Express is a user process. It is started by Visual Studio and runs as the same Windows account as the Visual Studio process. Two different processes running as the same Windows account (Visual Studio and IIS Express, both running as our Windows account) connecting to (localdb)\v11.0 are connecting to the same LocalDB process, also started as the same Windows account.
Possible Solutions
Understanding the nature of the problem brings multiple approaches to solving it. As different approaches have different tradeoffs, instead of prescribing one solution, below I presented three approaches that seem most viable to me. My hope is to hear from you about the one that worked best for you! Here is the list:
Approach 1: Run IIS as our Windows user
Approach 2: Use LocalDB Shared Instance
Approach 3: Use full SQL Server Express
Let's take a closer look at each of them.
Approach 1: Run IIS as our Windows user
If different user accounts are the problem, why not try to run our Web Application under our Windows account? Web Application would connect to the same LocalDB as Visual Studio and everything should just work.
Making the configuration change is relatively easy, just start IIS Manager and find the right Application Pool:
Open Advanced Settings screen (available in the context menu):
Click the little button in the Identity property to bring up the Application Pool Identity screen:
Starting the Web Application again will confirm that the problem is solved:
What are the drawbacks of this approach? Of course running Web Application under our account brings certain security risks. If someone hijacks our Web Application they will be able to access all system resources our account can. Running the Web Application as ApplicationPoolIdentity provides additional protection since ApplicationPoolIdentity accounts have very limited access to local system resources. Therefore I cannot recommend this approach in general, but when used with care it is a viable option in some cases.
Approach 2: Use LocalDB Shared Instance
We could also use an instance sharing feature of LocalDB. It allows us to share a LocalDB instance with other users on the same machine. The shared instance will be accessible under a public name.
The easiest way of sharing an instance is to use SqlLocalDB.exe utility. Just start an administrative command line prompt, and type the following command:
sqllocaldb share v11.0 IIS_DB
It will share the private LocalDB instance v11.0 under the public name IIS_DB. All users on the machine will be able to connect to this instance, using (localdb).\IIS_DB as a server address. Note the . before the instance name, indicating this is a shared instance name. We should replace the connection string in our Web Application with an updated one:
Data Source=(localdb)\.\IIS_DB;Initial Catalog=OldFashionedDB;Integrated Security=True
Before the shared instance can be used by the Web Application we need to start it and create logins for the ApplicationPoolIdentity. Starting the instance is easy, simply connecting to it from SQL Server Object Explorer will start it and keep it alive. Once we are in the SQL Server Object Explorer we can also create the login for ApplicationPoolIdentity. We could use the following query:
create login [IIS APPPOOL\ASP.NET v4.0] from windows;
exec sp_addsrvrolemember N'IIS APPPOOL\ASP.NET v4.0', sysadmin
This script gives full administrative access to our LocalDB instance to the ApplicationPoolIdentity account. Whenever possible, I would recommend using more limited, database-level or even table-level permissions.
Now we can run our Web Application again. This time it should work just fine:
What are the drawbacks of this approach? The main one is that, before Web Application can connect to the shared instance, we need to make sure the instance is started. For that to happen the Windows account that owns the instance must connect to it and the connection must be kept open, or the LocalDB instance will shut down.
Approach 3: Use full SQL Server Express
Since full IIS runs as a service, maybe using traditional, service-based SQL Server Express is the right approach? We could just install SQL Server 2012 Express RC0 and create the OldFashionedDB database in it. We can even use our brand new SQL Server Data Tools to do it, as it works with any SQL Server version and edition. Our connection string would have to change to:
Data Source=.\SQLEXPRESS;Initial Catalog=OldFashionedDB;Integrated Security=True
Of course, just as in the previous case, we would need to make sure the ApplicationPoolIdentity account has access to our SQL Server Express instance. We can use the same script as previously:
create login [IIS APPPOOL\ASP.NET v4.0] from windows;
exec sp_addsrvrolemember N'IIS APPPOOL\ASP.NET v4.0', sysadmin
After that, running our Web Application brings the happy picture again:
What are the drawbacks of this approach? Obviously we lose the benefits of using LocalDB. Installing SQL Server Express may take more time than LocalDB, and there may be some machine cleanup necessary for it to succeed. SQL Server Express Setup can be blocked by problems like corrupt WMI database, polluted registry or components left by SQL Server or Visual Studio CTPs and Betas. And SQL Server Express will continue running in the background even when not needed, as services do.
Other options
There are other approaches of using LocalDB under full IIS that are not covered here. We could embrace the Web Application's private LocalDB instance and communicate with it through the Web Application by executing T-SQL scripts from ASP.NET code. We could also use AttachDbFileName option of ADO.NET connection strings and use a database file (.mdf) that would be attached to both our LocalDB during development and Web Application's LocalDB for debugging. I tried both I found them too cumbersome to discuss further.
Based on the answer from #KrzysztofKozielczyk.
I originally posted an answer here:
https://stackoverflow.com/a/62810876/3850405
After following this I verified that Load User Profile was set to true for my Application Pool and then set setProfileEnvironment to true in applicationHost.config. I did the last part by editing applicationHost.config located at:
C:\Windows\System32\inetsrv\config\applicationHost.config
I have tried to configure alternate access mappings in my SharePoint 2010 which is installed in WorkGroup Windows Server 2008 R2 server but could not make it work.
Here are my steps.
Go to Central Administration-> Manage Web Application.
Select a web application and extend it.
Provide the my12server.com in the host header and leave other default values as it is. I changed the zone to Extranet.
Click Ok.
After sometime, it creates Web Application in SharePoint and Web Site in IIS.
I have changed my hosts file by adding entry
192.168.1.11 my12server.com
Browse the new extended. It asks for credential. Supplied the correct credential but nothing got display. Just a blank page.
Note: I have however successfully extended web application when the SharePoint 2010 is in domain machine.
Please advice me.
Thanks
Prakash
SharePoint is designed to work in domain environments only. In other words, you cannot expect to run it on an underlying Windows Server which joined into a workgroup and expect full functionality. Although there are blog posts around describing installation in a workgroup environment (or, better to say, using local accounts), I wouldn't recommend wasting time with such a mode of operation.
Furthermore, it doesn't make sense to extend a web application just for the sake of providing another hostname. Extending web applications multiple times is mostly useful when you need different authentication providers for each of them. In your simple case you can just configure multiple Alternate Access Mapping records for a single web application.
I had a SharePoint server, now i want to move this from one machine to another machine.
This is what i did for the migration.
I have just installed sharepoint server in my new machine and i have removed the Sharepoint_config and wss_content databased from the new server. and i have restored both the databases from the old server. Then i tried to run the Central Admin and i got Unable to connect to content database error.
Is replacing the DB is wrong. is there any other way to migrate SP server from one machine to another. I have tried my taking Farm backup and restore i had many problem with that. so i feel replacing DB would be better for me. any suggestions please?
Move SharePoint between servers is a huge effort.
Data in databases are very depends on the SharePoint install and its environments. So, I suggest just re-install the SharePoint on the new server, and then restore site collection backups to the new install.
Install SharePoint Server on the new server machine
Backup site collections from the old server, follow this guide: http://technet.microsoft.com/en-us/library/cc263441(v=office.12).aspx
Create Web Applications on the new server
Restore site collections from the prev. backups, follow this guide: http://technet.microsoft.com/en-us/library/cc262087(v=office.12).aspx
Be aware, if you have farm level customize solutions (developed by Visual Studio) or css files deployed in the LAYOUT folder, don't forget to re-deploy them on the new server.
I guess this question is too old and my answer will not help topicstarter... However, I was looking to refresh my own knowledge on this topic and I feel it will be useful to share it here.
This solution is not good for every SharePoint deployments, of course, it's just a general idea.
And I don't think it suits production environments well... but if you are brave and foolish as myself, you can do it there as well, with some additional precautions like backups and so on.
Here are prerequisites:
SharePoint was initially installed in Farm mode (not in Single Server mode)
Both old and new servers are in the same domain
You know Farm Passphrase used for initial installation
Old server is still intact and accessible from the new server
Steps to do
Skip steps 2-6 if you don't want to move databases to new location
Install SharePoint on the new server and join to existing farm. See
https://technet.microsoft.com/en-us/library/cc261752.aspx for details on joining procedure.
Ensure that the SharePoint is read-only. You can just shut down MS SQL DBEngine service if it's ok for your users.
Install MSSQL Server on the new server or other location you want. Remember, that it's not a good idea to keep SharePoint and MSSQL on the same server if it's not a demo/dev environment
Move all SharePoint databases to the new MSSQL Server. You can simply copy all DB files and attach it to the new SQL, or go full backup and restore way.
Important: Create an SQL client alias on the new server with cliconfg tool. See blogs.msdn.com/b/priyo/archive/2013/09/13/sql-alias-for-sharepoint.aspx for details.
Use your old SQL instance name as alias name. E.g. if your old server had SQL installed alongside with SharePoint on SharePoint.mydomain.com, alias name should be "SharePoint.mydomain.com"
Set Server name for alias to the new SQL location. Something like "NewServer.mydomain.com"
Ensure that you specify correct port number for SQL connection or configure network for default dynamic port. It is not necessary only if you have local SQL server on the same machine.
Create identical SQL client alias on the old server (this is needed to correctly remove old server from farm)
Remove old server from the farm. See this technet article for details
Update DNS settings or whatever you use to point users to the new server.
That's it. Hope it will help someone