We help IT Professionals succeed at work.

Sharepoint 2010 sp1 upgrade Always on SQL s012

592 Views
Last Modified: 2013-12-14
All,

Looking to move sharepoint 2010 to new app farm following sql farm move.

Moved SQL farm to new 2012 Always on group and set all db's into replication using SQL alias.

to move the app farm to new datacentre i have added teh new appservers to farm but to detach central admin and move it to new server i need to run SP configuration wizard on old server. Run this on old server and upgrade is pending.

Upgrade fails as the logging database cannot be set to simple mode as its part of a replication group.

i cannot follow usual method of stopping the mirror as the db is in Alwayson not a mirror.

the only method is below :
take the farm down
drop the logging db out of always on
point the  SQL alias  on the application and WFE at the primary node
run all the tasks to migrate to the new farm that involve the configuration wizard to ensure the logging db can go in and out of simple mode
once all tasks are complete re add the logging db into the always on farm
repoint all new farm servers at the Always on listener
bring farm back online

obviously thsi is going to have a big impact on downtime as prior to this discovery i was going to complete all reconfiguration, move of timer, crawl and central admin whilst the farm was online and the last task would be a repoint of DNS to the new WFE.

my question would be is their a method of running the configuration wizard without kicking the logging DB into simple recovery, or dropping the secondary replica but keeping the db active on the sql listener address so i dont need to repoint the sql alias.

Hoping someone can help with this,

jay
Comment
Watch Question

Ted BouskillSenior Software Developer
CERTIFIED EXPERT
Top Expert 2009
Commented:
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION

Author

Commented:
Hi Ted,

The process is fine and something I've followed multiple times in the past however never transferring the db's to an alwayson 2012 multi subnet failover. The process of moving to a new db farm is easily achieved using SQL alias and moving to new app wfe is again fairly easy using scale out process, transferring services, migrating wfe and re pointing DNS.

I have now resolved this using power shell to create a temporary logging db in the physical primary node, re pointing logging at this db and running the upgrade and transfer processes. Once these had completed and all migration tasks were complete I then transferred back to the original alwayson replicated db.
It's been a fun 24 hours but got there in the end!
Ted BouskillSenior Software Developer
CERTIFIED EXPERT
Top Expert 2009

Commented:
I guarantee that if Microsoft found out you did this and tried to get support for the farm you wouldn't get any support without paying for it.  I wouldn't do it for my farm.

Author

Commented:
I work for a Microsoft finalist database partner and it's not a new process  or methodology on migration just not standard so not sure where the foundation fir your guarentee stems from but no problem thanks  for the input
Senior Software Developer
CERTIFIED EXPERT
Top Expert 2009
Commented:
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.