How we can have the ability to build a new sharepoint server which have the same sharepoint patches installed
we have couple of sharepoint 2013/2016 farms, and they all shared these architecture :-
- one sharepoint application server which have sharepoint server installed.
- one database server which have the sharepoint databases installed.
Now as part of our backup policy, we do the following:-
- we perform a backup on the sharepoint databases.
- our database backups will be beneficial to us, in-case the database server got sever damage and we were not able to recover it back.
- but what about the case if our sharepoint application server crashed. then our database server and our database backups will not be beneficial to us.
now someone might say that i can build a new sharepoint application server, and configure it to run on existing database. but the problem in sharepoint , that the sharepoint application server need to have the same patch level as in the crashed server. by patch level, i mean all the sharepoint patches that are installed as part of windows updates (those updates can be found inside the control panel).
so my question is how we can backup those sharepoint patches?, in a way that can allow us to automatically install them in any new sharepoint server?
till i find a way to do so, i am currently taking a screenshot of our control panel, which includes the sharepoint updates we have, something as follow, this can allow us to know what are the updates that we need to install in-case we faced a situation that our current SharePoint server got sever damage and we want to build a new sharepoint server (of course i update this list after any patching we do on the server).
windows backup sql-server sharepoint sharepoint-2013
migrated from superuser.com Jan 17 at 16:35
This question came from our site for computer enthusiasts and power users.
|
show 5 more comments
we have couple of sharepoint 2013/2016 farms, and they all shared these architecture :-
- one sharepoint application server which have sharepoint server installed.
- one database server which have the sharepoint databases installed.
Now as part of our backup policy, we do the following:-
- we perform a backup on the sharepoint databases.
- our database backups will be beneficial to us, in-case the database server got sever damage and we were not able to recover it back.
- but what about the case if our sharepoint application server crashed. then our database server and our database backups will not be beneficial to us.
now someone might say that i can build a new sharepoint application server, and configure it to run on existing database. but the problem in sharepoint , that the sharepoint application server need to have the same patch level as in the crashed server. by patch level, i mean all the sharepoint patches that are installed as part of windows updates (those updates can be found inside the control panel).
so my question is how we can backup those sharepoint patches?, in a way that can allow us to automatically install them in any new sharepoint server?
till i find a way to do so, i am currently taking a screenshot of our control panel, which includes the sharepoint updates we have, something as follow, this can allow us to know what are the updates that we need to install in-case we faced a situation that our current SharePoint server got sever damage and we want to build a new sharepoint server (of course i update this list after any patching we do on the server).
windows backup sql-server sharepoint sharepoint-2013
migrated from superuser.com Jan 17 at 16:35
This question came from our site for computer enthusiasts and power users.
why i got down votes? any explanation will be useful..
– test test
Jan 15 at 16:17
I'm guessing it's because it's for a business and is considered off-topic for this site.
– HazardousGlitch
Jan 17 at 14:01
@HazardousGlitch i am asking a question about how we can document/backup the sharepoint patches info that we have. so we can apply the same sharepoint patches if/when need inside a new server.
– test test
Jan 17 at 14:34
1
You mentioned a SharePoint server farm which probably means it's for a corporation which is beyond the scope of this site. Even if it isn't a corporation, I believe it's still beyond the scope. You're better off asking on ServerFault as it's better designed to handle these types of questions. That is probably why you were down voted.
– HazardousGlitch
Jan 17 at 14:50
2
This should have been migrated to SharePoint...
– Sven♦
Jan 17 at 19:57
|
show 5 more comments
we have couple of sharepoint 2013/2016 farms, and they all shared these architecture :-
- one sharepoint application server which have sharepoint server installed.
- one database server which have the sharepoint databases installed.
Now as part of our backup policy, we do the following:-
- we perform a backup on the sharepoint databases.
- our database backups will be beneficial to us, in-case the database server got sever damage and we were not able to recover it back.
- but what about the case if our sharepoint application server crashed. then our database server and our database backups will not be beneficial to us.
now someone might say that i can build a new sharepoint application server, and configure it to run on existing database. but the problem in sharepoint , that the sharepoint application server need to have the same patch level as in the crashed server. by patch level, i mean all the sharepoint patches that are installed as part of windows updates (those updates can be found inside the control panel).
so my question is how we can backup those sharepoint patches?, in a way that can allow us to automatically install them in any new sharepoint server?
till i find a way to do so, i am currently taking a screenshot of our control panel, which includes the sharepoint updates we have, something as follow, this can allow us to know what are the updates that we need to install in-case we faced a situation that our current SharePoint server got sever damage and we want to build a new sharepoint server (of course i update this list after any patching we do on the server).
windows backup sql-server sharepoint sharepoint-2013
we have couple of sharepoint 2013/2016 farms, and they all shared these architecture :-
- one sharepoint application server which have sharepoint server installed.
- one database server which have the sharepoint databases installed.
Now as part of our backup policy, we do the following:-
- we perform a backup on the sharepoint databases.
- our database backups will be beneficial to us, in-case the database server got sever damage and we were not able to recover it back.
- but what about the case if our sharepoint application server crashed. then our database server and our database backups will not be beneficial to us.
now someone might say that i can build a new sharepoint application server, and configure it to run on existing database. but the problem in sharepoint , that the sharepoint application server need to have the same patch level as in the crashed server. by patch level, i mean all the sharepoint patches that are installed as part of windows updates (those updates can be found inside the control panel).
so my question is how we can backup those sharepoint patches?, in a way that can allow us to automatically install them in any new sharepoint server?
till i find a way to do so, i am currently taking a screenshot of our control panel, which includes the sharepoint updates we have, something as follow, this can allow us to know what are the updates that we need to install in-case we faced a situation that our current SharePoint server got sever damage and we want to build a new sharepoint server (of course i update this list after any patching we do on the server).
windows backup sql-server sharepoint sharepoint-2013
windows backup sql-server sharepoint sharepoint-2013
asked Jan 15 at 15:46
test testtest test
315
315
migrated from superuser.com Jan 17 at 16:35
This question came from our site for computer enthusiasts and power users.
migrated from superuser.com Jan 17 at 16:35
This question came from our site for computer enthusiasts and power users.
why i got down votes? any explanation will be useful..
– test test
Jan 15 at 16:17
I'm guessing it's because it's for a business and is considered off-topic for this site.
– HazardousGlitch
Jan 17 at 14:01
@HazardousGlitch i am asking a question about how we can document/backup the sharepoint patches info that we have. so we can apply the same sharepoint patches if/when need inside a new server.
– test test
Jan 17 at 14:34
1
You mentioned a SharePoint server farm which probably means it's for a corporation which is beyond the scope of this site. Even if it isn't a corporation, I believe it's still beyond the scope. You're better off asking on ServerFault as it's better designed to handle these types of questions. That is probably why you were down voted.
– HazardousGlitch
Jan 17 at 14:50
2
This should have been migrated to SharePoint...
– Sven♦
Jan 17 at 19:57
|
show 5 more comments
why i got down votes? any explanation will be useful..
– test test
Jan 15 at 16:17
I'm guessing it's because it's for a business and is considered off-topic for this site.
– HazardousGlitch
Jan 17 at 14:01
@HazardousGlitch i am asking a question about how we can document/backup the sharepoint patches info that we have. so we can apply the same sharepoint patches if/when need inside a new server.
– test test
Jan 17 at 14:34
1
You mentioned a SharePoint server farm which probably means it's for a corporation which is beyond the scope of this site. Even if it isn't a corporation, I believe it's still beyond the scope. You're better off asking on ServerFault as it's better designed to handle these types of questions. That is probably why you were down voted.
– HazardousGlitch
Jan 17 at 14:50
2
This should have been migrated to SharePoint...
– Sven♦
Jan 17 at 19:57
why i got down votes? any explanation will be useful..
– test test
Jan 15 at 16:17
why i got down votes? any explanation will be useful..
– test test
Jan 15 at 16:17
I'm guessing it's because it's for a business and is considered off-topic for this site.
– HazardousGlitch
Jan 17 at 14:01
I'm guessing it's because it's for a business and is considered off-topic for this site.
– HazardousGlitch
Jan 17 at 14:01
@HazardousGlitch i am asking a question about how we can document/backup the sharepoint patches info that we have. so we can apply the same sharepoint patches if/when need inside a new server.
– test test
Jan 17 at 14:34
@HazardousGlitch i am asking a question about how we can document/backup the sharepoint patches info that we have. so we can apply the same sharepoint patches if/when need inside a new server.
– test test
Jan 17 at 14:34
1
1
You mentioned a SharePoint server farm which probably means it's for a corporation which is beyond the scope of this site. Even if it isn't a corporation, I believe it's still beyond the scope. You're better off asking on ServerFault as it's better designed to handle these types of questions. That is probably why you were down voted.
– HazardousGlitch
Jan 17 at 14:50
You mentioned a SharePoint server farm which probably means it's for a corporation which is beyond the scope of this site. Even if it isn't a corporation, I believe it's still beyond the scope. You're better off asking on ServerFault as it's better designed to handle these types of questions. That is probably why you were down voted.
– HazardousGlitch
Jan 17 at 14:50
2
2
This should have been migrated to SharePoint...
– Sven♦
Jan 17 at 19:57
This should have been migrated to SharePoint...
– Sven♦
Jan 17 at 19:57
|
show 5 more comments
2 Answers
2
active
oldest
votes
Have a look at the documentation (which you should do anyway, because updating SharePoint is definitely not as straightforward as other products).
For SharePoint 2013, updates have been cumulative since Service Pack 1, thus you only need to keep track of the last update you install. If/when you need to build a replacement server, just apply SP1, then the same update as the originale server; you don't need to apply all the ones before.
The situation is quite more complex for SharePoint 2016, as there have been several non-cumulative updates; only after KB4011127 updates have started replacing previous ones. So you need to at least get there before installing the same update that was installed on the original server.
thanks for the reply. now in sharepoint on-premises 2013, sometimes our admin install security updates (for sharepoint & windows) and some of the sharepoint security updates will raise the sharepoint farm build number. so in sharepoint on-premises 2013 not all the updates are been done as part of a full CU, as we can install separate sharepoint security updates without having to install a full CU...
– test test
Jan 17 at 18:06
Does your admin install everything that pops up on Windows Update? Is he/she aware that it's required to actually run the SharePoint Product Configuration Wizard after each and every SharePoint update?
– Massimo
Jan 17 at 18:11
yes after patching the sharepoint server we run the product configuration wizard,, we are already aware of this..
– test test
Jan 17 at 18:12
1
Ok, good. But SP2013 CUs are released monthly, you probably don't need so fast a patch cycle. Anyway, the approach is the same: just keep track of the last installed CU and of any update installed after that; everything before the last CU is not needed, because it's included in the CU.
– Massimo
Jan 17 at 18:14
2
@Massimo: Just FYI: Unfortunately, we can't migrate to a 3rd site after it has been migrated here. I could only close it, which would send it back to SU...
– Sven♦
Jan 17 at 19:59
|
show 9 more comments
Another answer for a different approach to the problem: why don't you just backup the whole server?
If it's a virtual machine (most servers are, nowadays) it should be really easy to take a backup, or even to make a clone, after applying an update. But even if it's a physical server, there are solutions for that.
Restoring a backup is much quicker than building a replacement server.
yes the sharepoint server and the dataabse server are VMs... but the problem is that snapshots are not supported in sharepoint... or you mean i can reference the snapshot to get what are the patches that we need to install inside any new VM?
– test test
Jan 17 at 18:11
I'm not talking about snapshots, I'm talking about backups (they are not the same). But if you are concerned about taking an image of a running system, just turn off the server and make a full copy of its virtual disk(s). You need to reboot it anyway if you have installed updates; a couple minutes of additional downtime shouldn't matter and will make a restore a lot quicker and easier than building another server.
– Massimo
Jan 17 at 18:22
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f949570%2fhow-we-can-have-the-ability-to-build-a-new-sharepoint-server-which-have-the-same%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Have a look at the documentation (which you should do anyway, because updating SharePoint is definitely not as straightforward as other products).
For SharePoint 2013, updates have been cumulative since Service Pack 1, thus you only need to keep track of the last update you install. If/when you need to build a replacement server, just apply SP1, then the same update as the originale server; you don't need to apply all the ones before.
The situation is quite more complex for SharePoint 2016, as there have been several non-cumulative updates; only after KB4011127 updates have started replacing previous ones. So you need to at least get there before installing the same update that was installed on the original server.
thanks for the reply. now in sharepoint on-premises 2013, sometimes our admin install security updates (for sharepoint & windows) and some of the sharepoint security updates will raise the sharepoint farm build number. so in sharepoint on-premises 2013 not all the updates are been done as part of a full CU, as we can install separate sharepoint security updates without having to install a full CU...
– test test
Jan 17 at 18:06
Does your admin install everything that pops up on Windows Update? Is he/she aware that it's required to actually run the SharePoint Product Configuration Wizard after each and every SharePoint update?
– Massimo
Jan 17 at 18:11
yes after patching the sharepoint server we run the product configuration wizard,, we are already aware of this..
– test test
Jan 17 at 18:12
1
Ok, good. But SP2013 CUs are released monthly, you probably don't need so fast a patch cycle. Anyway, the approach is the same: just keep track of the last installed CU and of any update installed after that; everything before the last CU is not needed, because it's included in the CU.
– Massimo
Jan 17 at 18:14
2
@Massimo: Just FYI: Unfortunately, we can't migrate to a 3rd site after it has been migrated here. I could only close it, which would send it back to SU...
– Sven♦
Jan 17 at 19:59
|
show 9 more comments
Have a look at the documentation (which you should do anyway, because updating SharePoint is definitely not as straightforward as other products).
For SharePoint 2013, updates have been cumulative since Service Pack 1, thus you only need to keep track of the last update you install. If/when you need to build a replacement server, just apply SP1, then the same update as the originale server; you don't need to apply all the ones before.
The situation is quite more complex for SharePoint 2016, as there have been several non-cumulative updates; only after KB4011127 updates have started replacing previous ones. So you need to at least get there before installing the same update that was installed on the original server.
thanks for the reply. now in sharepoint on-premises 2013, sometimes our admin install security updates (for sharepoint & windows) and some of the sharepoint security updates will raise the sharepoint farm build number. so in sharepoint on-premises 2013 not all the updates are been done as part of a full CU, as we can install separate sharepoint security updates without having to install a full CU...
– test test
Jan 17 at 18:06
Does your admin install everything that pops up on Windows Update? Is he/she aware that it's required to actually run the SharePoint Product Configuration Wizard after each and every SharePoint update?
– Massimo
Jan 17 at 18:11
yes after patching the sharepoint server we run the product configuration wizard,, we are already aware of this..
– test test
Jan 17 at 18:12
1
Ok, good. But SP2013 CUs are released monthly, you probably don't need so fast a patch cycle. Anyway, the approach is the same: just keep track of the last installed CU and of any update installed after that; everything before the last CU is not needed, because it's included in the CU.
– Massimo
Jan 17 at 18:14
2
@Massimo: Just FYI: Unfortunately, we can't migrate to a 3rd site after it has been migrated here. I could only close it, which would send it back to SU...
– Sven♦
Jan 17 at 19:59
|
show 9 more comments
Have a look at the documentation (which you should do anyway, because updating SharePoint is definitely not as straightforward as other products).
For SharePoint 2013, updates have been cumulative since Service Pack 1, thus you only need to keep track of the last update you install. If/when you need to build a replacement server, just apply SP1, then the same update as the originale server; you don't need to apply all the ones before.
The situation is quite more complex for SharePoint 2016, as there have been several non-cumulative updates; only after KB4011127 updates have started replacing previous ones. So you need to at least get there before installing the same update that was installed on the original server.
Have a look at the documentation (which you should do anyway, because updating SharePoint is definitely not as straightforward as other products).
For SharePoint 2013, updates have been cumulative since Service Pack 1, thus you only need to keep track of the last update you install. If/when you need to build a replacement server, just apply SP1, then the same update as the originale server; you don't need to apply all the ones before.
The situation is quite more complex for SharePoint 2016, as there have been several non-cumulative updates; only after KB4011127 updates have started replacing previous ones. So you need to at least get there before installing the same update that was installed on the original server.
edited Jan 17 at 17:24
answered Jan 17 at 17:09
MassimoMassimo
52.5k44164280
52.5k44164280
thanks for the reply. now in sharepoint on-premises 2013, sometimes our admin install security updates (for sharepoint & windows) and some of the sharepoint security updates will raise the sharepoint farm build number. so in sharepoint on-premises 2013 not all the updates are been done as part of a full CU, as we can install separate sharepoint security updates without having to install a full CU...
– test test
Jan 17 at 18:06
Does your admin install everything that pops up on Windows Update? Is he/she aware that it's required to actually run the SharePoint Product Configuration Wizard after each and every SharePoint update?
– Massimo
Jan 17 at 18:11
yes after patching the sharepoint server we run the product configuration wizard,, we are already aware of this..
– test test
Jan 17 at 18:12
1
Ok, good. But SP2013 CUs are released monthly, you probably don't need so fast a patch cycle. Anyway, the approach is the same: just keep track of the last installed CU and of any update installed after that; everything before the last CU is not needed, because it's included in the CU.
– Massimo
Jan 17 at 18:14
2
@Massimo: Just FYI: Unfortunately, we can't migrate to a 3rd site after it has been migrated here. I could only close it, which would send it back to SU...
– Sven♦
Jan 17 at 19:59
|
show 9 more comments
thanks for the reply. now in sharepoint on-premises 2013, sometimes our admin install security updates (for sharepoint & windows) and some of the sharepoint security updates will raise the sharepoint farm build number. so in sharepoint on-premises 2013 not all the updates are been done as part of a full CU, as we can install separate sharepoint security updates without having to install a full CU...
– test test
Jan 17 at 18:06
Does your admin install everything that pops up on Windows Update? Is he/she aware that it's required to actually run the SharePoint Product Configuration Wizard after each and every SharePoint update?
– Massimo
Jan 17 at 18:11
yes after patching the sharepoint server we run the product configuration wizard,, we are already aware of this..
– test test
Jan 17 at 18:12
1
Ok, good. But SP2013 CUs are released monthly, you probably don't need so fast a patch cycle. Anyway, the approach is the same: just keep track of the last installed CU and of any update installed after that; everything before the last CU is not needed, because it's included in the CU.
– Massimo
Jan 17 at 18:14
2
@Massimo: Just FYI: Unfortunately, we can't migrate to a 3rd site after it has been migrated here. I could only close it, which would send it back to SU...
– Sven♦
Jan 17 at 19:59
thanks for the reply. now in sharepoint on-premises 2013, sometimes our admin install security updates (for sharepoint & windows) and some of the sharepoint security updates will raise the sharepoint farm build number. so in sharepoint on-premises 2013 not all the updates are been done as part of a full CU, as we can install separate sharepoint security updates without having to install a full CU...
– test test
Jan 17 at 18:06
thanks for the reply. now in sharepoint on-premises 2013, sometimes our admin install security updates (for sharepoint & windows) and some of the sharepoint security updates will raise the sharepoint farm build number. so in sharepoint on-premises 2013 not all the updates are been done as part of a full CU, as we can install separate sharepoint security updates without having to install a full CU...
– test test
Jan 17 at 18:06
Does your admin install everything that pops up on Windows Update? Is he/she aware that it's required to actually run the SharePoint Product Configuration Wizard after each and every SharePoint update?
– Massimo
Jan 17 at 18:11
Does your admin install everything that pops up on Windows Update? Is he/she aware that it's required to actually run the SharePoint Product Configuration Wizard after each and every SharePoint update?
– Massimo
Jan 17 at 18:11
yes after patching the sharepoint server we run the product configuration wizard,, we are already aware of this..
– test test
Jan 17 at 18:12
yes after patching the sharepoint server we run the product configuration wizard,, we are already aware of this..
– test test
Jan 17 at 18:12
1
1
Ok, good. But SP2013 CUs are released monthly, you probably don't need so fast a patch cycle. Anyway, the approach is the same: just keep track of the last installed CU and of any update installed after that; everything before the last CU is not needed, because it's included in the CU.
– Massimo
Jan 17 at 18:14
Ok, good. But SP2013 CUs are released monthly, you probably don't need so fast a patch cycle. Anyway, the approach is the same: just keep track of the last installed CU and of any update installed after that; everything before the last CU is not needed, because it's included in the CU.
– Massimo
Jan 17 at 18:14
2
2
@Massimo: Just FYI: Unfortunately, we can't migrate to a 3rd site after it has been migrated here. I could only close it, which would send it back to SU...
– Sven♦
Jan 17 at 19:59
@Massimo: Just FYI: Unfortunately, we can't migrate to a 3rd site after it has been migrated here. I could only close it, which would send it back to SU...
– Sven♦
Jan 17 at 19:59
|
show 9 more comments
Another answer for a different approach to the problem: why don't you just backup the whole server?
If it's a virtual machine (most servers are, nowadays) it should be really easy to take a backup, or even to make a clone, after applying an update. But even if it's a physical server, there are solutions for that.
Restoring a backup is much quicker than building a replacement server.
yes the sharepoint server and the dataabse server are VMs... but the problem is that snapshots are not supported in sharepoint... or you mean i can reference the snapshot to get what are the patches that we need to install inside any new VM?
– test test
Jan 17 at 18:11
I'm not talking about snapshots, I'm talking about backups (they are not the same). But if you are concerned about taking an image of a running system, just turn off the server and make a full copy of its virtual disk(s). You need to reboot it anyway if you have installed updates; a couple minutes of additional downtime shouldn't matter and will make a restore a lot quicker and easier than building another server.
– Massimo
Jan 17 at 18:22
add a comment |
Another answer for a different approach to the problem: why don't you just backup the whole server?
If it's a virtual machine (most servers are, nowadays) it should be really easy to take a backup, or even to make a clone, after applying an update. But even if it's a physical server, there are solutions for that.
Restoring a backup is much quicker than building a replacement server.
yes the sharepoint server and the dataabse server are VMs... but the problem is that snapshots are not supported in sharepoint... or you mean i can reference the snapshot to get what are the patches that we need to install inside any new VM?
– test test
Jan 17 at 18:11
I'm not talking about snapshots, I'm talking about backups (they are not the same). But if you are concerned about taking an image of a running system, just turn off the server and make a full copy of its virtual disk(s). You need to reboot it anyway if you have installed updates; a couple minutes of additional downtime shouldn't matter and will make a restore a lot quicker and easier than building another server.
– Massimo
Jan 17 at 18:22
add a comment |
Another answer for a different approach to the problem: why don't you just backup the whole server?
If it's a virtual machine (most servers are, nowadays) it should be really easy to take a backup, or even to make a clone, after applying an update. But even if it's a physical server, there are solutions for that.
Restoring a backup is much quicker than building a replacement server.
Another answer for a different approach to the problem: why don't you just backup the whole server?
If it's a virtual machine (most servers are, nowadays) it should be really easy to take a backup, or even to make a clone, after applying an update. But even if it's a physical server, there are solutions for that.
Restoring a backup is much quicker than building a replacement server.
answered Jan 17 at 18:08
MassimoMassimo
52.5k44164280
52.5k44164280
yes the sharepoint server and the dataabse server are VMs... but the problem is that snapshots are not supported in sharepoint... or you mean i can reference the snapshot to get what are the patches that we need to install inside any new VM?
– test test
Jan 17 at 18:11
I'm not talking about snapshots, I'm talking about backups (they are not the same). But if you are concerned about taking an image of a running system, just turn off the server and make a full copy of its virtual disk(s). You need to reboot it anyway if you have installed updates; a couple minutes of additional downtime shouldn't matter and will make a restore a lot quicker and easier than building another server.
– Massimo
Jan 17 at 18:22
add a comment |
yes the sharepoint server and the dataabse server are VMs... but the problem is that snapshots are not supported in sharepoint... or you mean i can reference the snapshot to get what are the patches that we need to install inside any new VM?
– test test
Jan 17 at 18:11
I'm not talking about snapshots, I'm talking about backups (they are not the same). But if you are concerned about taking an image of a running system, just turn off the server and make a full copy of its virtual disk(s). You need to reboot it anyway if you have installed updates; a couple minutes of additional downtime shouldn't matter and will make a restore a lot quicker and easier than building another server.
– Massimo
Jan 17 at 18:22
yes the sharepoint server and the dataabse server are VMs... but the problem is that snapshots are not supported in sharepoint... or you mean i can reference the snapshot to get what are the patches that we need to install inside any new VM?
– test test
Jan 17 at 18:11
yes the sharepoint server and the dataabse server are VMs... but the problem is that snapshots are not supported in sharepoint... or you mean i can reference the snapshot to get what are the patches that we need to install inside any new VM?
– test test
Jan 17 at 18:11
I'm not talking about snapshots, I'm talking about backups (they are not the same). But if you are concerned about taking an image of a running system, just turn off the server and make a full copy of its virtual disk(s). You need to reboot it anyway if you have installed updates; a couple minutes of additional downtime shouldn't matter and will make a restore a lot quicker and easier than building another server.
– Massimo
Jan 17 at 18:22
I'm not talking about snapshots, I'm talking about backups (they are not the same). But if you are concerned about taking an image of a running system, just turn off the server and make a full copy of its virtual disk(s). You need to reboot it anyway if you have installed updates; a couple minutes of additional downtime shouldn't matter and will make a restore a lot quicker and easier than building another server.
– Massimo
Jan 17 at 18:22
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f949570%2fhow-we-can-have-the-ability-to-build-a-new-sharepoint-server-which-have-the-same%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
why i got down votes? any explanation will be useful..
– test test
Jan 15 at 16:17
I'm guessing it's because it's for a business and is considered off-topic for this site.
– HazardousGlitch
Jan 17 at 14:01
@HazardousGlitch i am asking a question about how we can document/backup the sharepoint patches info that we have. so we can apply the same sharepoint patches if/when need inside a new server.
– test test
Jan 17 at 14:34
1
You mentioned a SharePoint server farm which probably means it's for a corporation which is beyond the scope of this site. Even if it isn't a corporation, I believe it's still beyond the scope. You're better off asking on ServerFault as it's better designed to handle these types of questions. That is probably why you were down voted.
– HazardousGlitch
Jan 17 at 14:50
2
This should have been migrated to SharePoint...
– Sven♦
Jan 17 at 19:57