I'm a sharepoint newbie and I'm on the installation phase.
My question is:
Can 2 sharepoint servers (different versions & running on separate machines) point to the same configuration database?
Thanks in advance!
No.
Several SharePoint servers within the same farm (which is an logical concept in SharePoint) do need to point to the same configuration database. However, in your case where you have 2 different versions (I assume you're talking SharePoint 2010 and 2013), that will not work as there are differences in the configuration databases between the two versions.
It is totally okay though to host multiple configuration databases on the same SQL server if you want.
Related
I am working with a customer which have SharePoint 2013 dev, test and prod environments sitting in a datacentre. We are moving the datacentre which means their SharePoint 2013 needs to be moved as is. They have 1 heavly custom build application on top of SharePoint which needs to be moved. I need confirmation, process suggestion on the migration part.
I install SharePoint 2013 like for like in new environment.
Option 1
I take backup for their databases and restore them on new SQL Server. Use Mount-SPContentDatabase to mount database and test if everything is working as expected
Option 2
Recreate web application, site collections, activate custom features, timer job and migrate content.
I personally think that option 1 is more applicable but need input and suggestions. Any road blockers or gotcha are also encouraged.
Thanks for sharing your experience
As its a same version migration it wont be much of an issue but go with option 1.
Re Creating the whole farm is so hard specially if you decide to deploy each and every component.
I've migrations to same version and these are the steps that i follow.
Create a checklist of all solutions and features (WSP etc).
The check list should have the same services that are running in the farm as well.
Install SharePoint in the new farm and update to the same version as the existing farm , having same version will reduce a lot of
problems.
Create the service applications just like the existing farm.
Restore the service application databases (MetaData, UserProfile etc)
Create the web application and restore the content database
Deploy the custom solutions
Confirm that everything in your checklist is deployed and working fine
Fix errors if there are any
This is the flow that i follow and so far i've been successful.
Good Luck
I currently have SharePoint Foundations 2010 set up in our network. I have been directed to bring up SharePoint Foundations 2013 for a separate project. We would then slowly migrate all data to SharePoint 2013. Is it possible to have two completely separate SharePoint instances in one domain? Assuming of course that they would each be on their own front end server and sql database servers.
Yes, you can have any number of instances of SharePoint in the same domain. It will not be an issue.
JD
Yes, you can have two instances of SharePoint, but the urls need to be slightly different, just as the servers need to have different names.
That's not a bad strategy for upgrading if you don't have gobs of content that would have to be moved over right away.
Here's an example, if your domain is xyz.com and your first sharepoint server uses xyz.com, you could set your second instance up as sharepoint.xyz.com
You would just need to make sure you had dns set up to point sharepoint.xyz.com to your second server's ip address.
I'm in a machine that has already SharePoint installed, so when I started the SharePoint Central Administration to config, this message appear to me: "Can not connect to the database configuration."
How do I know which database is configured SharePoint?
Normally the Admin database is created using the naming convention SharePoint_AdminContent_{GUID}. However if there's more than one, you'll need to use SQL Management studo or other tool to look inside the DBs, look for a table called "DatabaseInformation" which will contain two items, look in the AlternateAccessMappingXML entry and look for the XML tage IncomingUrl, that should help you narrow it down.
Or just use the SQL profiler and watch for connections.
By default SharePoint will install the Database on the same machine as the web server, but you can ask whoever installed SharePoint on the machine.
Anyhow, most likely it's not relevant and something else is the problem, follow the resolution methods described here and you'll probably have it fixed.
This is a rather general question but I'm trying to assess what best approach to take when it comes to deploying SharePoint solutions onto load balanced environments.
Let's assume we have the following:
WebServer-01 and WebServer-02
Our SharePoint installation is balanced over these two environments, but as a developer, I only have access to WebServer-01 for deployment. The assumption here is that the infrastructure guys set up a replication from 01 to 02 but did not set up a replication for configuration files.
What would be the best, out of experience, approach to replicate the configuration file to the second server, without tweaking the replication script or logging into the box?
I was thinking of creating a deployment package, for example click-once that injects the required appSettings, but this in itself is risky?
Thanks,
Eric
If you deploy everything the 'SharePoint way', as in building WSP packages, then there is no need to manually replicate settings across multiple servers in the same Farm. SharePoint takes care of it.
You may want to consider posting SharePoint related questions on sharepoint.stackexchange.com
Some further helpful tips
SharePoint Development Guidelines.
Creating a Solution Package in Windows SharePoint Services 3.0
Creating a SharePoint Solution Package (.wsp) in 5 steps
WSPBuilder.
I need to migrate our SharePoint farm to a new domain. Until everything is moved we have full trust set up between the domains.
Farm Hardware
One WFE/Index Server
Two SQL DB Servers (clustered)
I know how to do this using all new hardware from production to a dev environment but doing an in place migration seems more daunting. To take some of the pressure off we have a new beefy SharePoint box to install to that will be a fresh box on the new domain but we don't have enough hardware to have a separate SQL cluster.
I am told that all the boxes should be on the same domain so now the hard part is to bring the SQL box on the new domain. Can I just switch domains on the SQL DB cluster and then install SP on the new WFE?
Voted to move to serverfault, but here's my 2 cents. Moving SQL Server 2 a new domain is easy, sql server will pick up any changes. The problem is sharepoint. SharePoint users to be exact.
Any documents in your site(s) will have it's created by / modified by broken, because even though the same users exist in the new domain, the bindings will be incorrect, sharepoint expects for instance user userA#olddomain.local, which is very different from user userA#newdomain.local. There is a way around this using httpmodules etc, but it is a pain in the ass.
Check out the result when googling migrate sharepoint new domain.
I've run a similar setup before. If they're full trust, you should be able to reconnect to your pre-existing config/content dbs from the new SharePoint instance in the new domain.
SQL server
You can have your SQL server in a different domain as long as there is a trust between the domains.
Migrating users
With regards to migrating your users, it's a daunting task because those user's SIDS own objects, I've used stsadm -o migrateuser but it's not terribly helpful, I'd consider looking into 3rd party software such as DocAve who have products that assist in migrating SharePoint content. If you really want to hack it, break open the Users table in your content databases and write a script to update the usernames and sids.