One way to replace the hardware for a Secondary Site
from Sherry ==> https://myitforum.com/cs2/blogs/skissinger/archive/2008/07/09/one-way-to-replace-the-hardware-for-a-secondary-site.aspx Tools needed:
- Preinst.exe from SMS 2003 Toolkit 2 https://www.microsoft.com/smserver/downloads/2003/tools/toolkit.mspx
- PreLoadPkgonSite also from SMS 2003 Toolkit 2
- CloneDP, installed (pre-req of .Net 2) https://sourceforge.net/projects/smsclonedp/
- Script or method to enumerate .pkg files in X:smspkg
- MPTroubleshooter also from SMS2003 Toolkit 2
Resources needed locally on the new server:
- SMS 2003 Setup files
- If secondary is to be a proxy MP, setup files for the Operating System
- Restored or copied from old server, X:smspkg
- Restored or copied from old server, X:smspkgx$ ** (Any steps marked with a ** are optional, see footnote)
Resources needed remotely: Rights and ability to remote into any primary sites above the secondary site to be replaced. Timeline – There are 4 time frames
- Tasks that can done before the new hardware is shipped to the destination; but could also be done once hardware arrives at new location.
- Tasks done after the new hardware has arrived.
- Work done after SMS 2003 reinstalled
- Follow up the next day.
Prior to shipping hardware
- From a local Distribution Point, copy otherserverx$smspkg to x:smspkg
- From a local Distribution Point, copy otherserverx$smspkgx$ to x:smspkgx$ **
- Copy SMS 2003 setup files to x:SMSToolssetup
- Copy PreloadPkgonSite.exe to x:SMSTools
- Copy PreloadBuild.vbs to x:SMSTools
The above steps could also be done once the hardware arrives at the destination, or restored from backup–if you backup your secondary (which we don’t normally) Hardware arrived
- Optional: if you copied smspkg & smspkgx$ over from ServerOld to ServerNew a significant time ago, you may want to do a Delta copy just before starting. Otherwise, if you preloadpkgonsite of an old version of a pkg file, those packages will need to be re-replicated from the parent.
- On Current Server, Disable the SMS Services so they do not launch automatically following a reboot.
- Rename current Server to ServerName_OLD, change IP address from static to dhcp. Reboot.
- On new hardware, rename to ServerName, change IP from dhcp to static. Reboot.
- Install IIS with BITS. If IIS had been installed under the old name, uninstall IIS, then reinstall IIS. This is to ensure the iis usernames are defined correctly.
- Follow the EdNet instructions for removing the Secondary Site from the Primary Site(s) databases, and deleting any jobs. These instructions use the preinst.exe toolkit tool at the Primary Site, and Query Analyzer. (https://www.myitforum.com/articles/1/view.asp?id=5355)
- Remove the SMS entries for the server in Active Directory for the server itself, and for the MP record. (in the OU SystemSystem Management, SMS-Site-xxx, and SMS-MP-xxx-ServerName)
- At the Primary Site(s), remove the Standard Sender Address for the secondary site. Wait a minute or so.
- At the Primary Sites(s), create a new Standard Sender Address for the secondary site.
- At the secondary site, unshare smspkge$ & rename to smspkge_old (you’ll move files later)**
- At the secondary site, install SMS from smstools…setup.exe, Advanced Security, Remote Tools enabled.
- Monitor smslogs*.log files for errors
- Monitor Active Directory Users and Computers, the OU System/System Management, for SMS-Site-Rxx to appear.
- At the direct Primary site, refresh Site hierarchy occasionally. When you see the site reappear, configure boundaries, Addresses, client Agents, Discovery Methods. Configure Site Systems to be a Management Point, and Distribution Point with BITS.
- At the secondary site, monitor smslogsmpsetup.log for success/failure.
If failed, stop and troubleshoot. Multiple problems can occur with this step. Too many to detail here.
If success, run the MP troubleshooter to verify.
SMS Reinstalled
- Push down 1 (smallish) package. Monitor the Secondary Site recreating smspkge$ share, and putting the new package in there.
- Highlight all the folders in smspkge_old, and verify the ntfs permissions match what they should be in the new smspkge$. Reset as necessary. Once satisfied permissions are correct, Move all the folders (except the new one you just had rebuilt) to the new smspkge$. You can delete smspkge_old when done (there should only be 1 folder left). **
- At the secondary, go to a command prompt. CD to x:smspkg Pick 1 package. Type in x:smstoolspreloadpkgonsite PackageID (without the .pkg extension, i.e., x:smstoolspreloadpkgonsite TST00012)
- A success message looks like this:
Forward package status for pkg C0100012 to site C01
****** Successfully set the Compressed Package Path on this site ******
****** Successfully forwarded the information up the hierarchy ******
If you got a different message (a failure message), try a different package. If all Packages fail, you may need to check that *.pkg are all Read-only. - Following the success message, monitor distmgr.log on the Secondary to confirm that package’s info has been sent.
- At the Central Site, add the (new) Secondary site distribution point to that 1 package.
- Monitor Sender.log at the server(s). Monitor Package Status at the Primary Site server(s).
- Once you are satisfied the process works, use this script to create a batch file in e:smspkg to run preloadpkgonsite against all the .pkg files.
- Edit: instead of steps 9, 10, 11; check out Marcus Oh’s blog entry on using PreloadPkgOnSite
Create a preloadbuild.vbs file with the below in e:smstools. Then start, run wscript e:smstoolspreloadbuild.vbs
The script (correct the variables for your environment/server; the E: drive may not be correct for you):
set fso = wscript.CreateObject(“Scripting.FileSystemObject”)
set fo = fso.getFolder(“e:smspkg”)
set fc = fo.Files
set TheFile = fso.createtextfile(“e:smspkgpreload.bat”,True)
For each file in fc
TheArray = Split(file,””, -1, 1)
StrNameToLoad = Left(TheArray(2),8)
theFile.writeline “e:smstoolspreloadpkgonsite ” & strNameToLoad & ” >> e:smstoolspreload1.txt”
next
TheFile.Close - Now that you have a e:smspkgpreload.bat, go to a cmd prompt, and switch to e:smspkg. Type in preload.bat, and wait.
- When it is done, open up e:smstoolspreload1.txt and verify the majority of the entries are “successfully forwarded”. It’s OK if there are a few errors, but if all are errors, there may be a problem.
- Watch distmgr.log on the secondary; wait for it to complete sending up packages (how long depends upon how many packages you have, this can take quite a while for me).
- After waiting, add the new DP to a package at the Central Site, and confirm via watching sender.log that the entire package is indeed NOT being replicated downward.
- Once you’ve confirmed that, run CloneDP, and pick a similar Secondary Site to Clone to the new one. It may take quite a while for CloneDP to go through the entire list of packages to Clone. This is normal; just wait.
CloneDP usage
- Launch
- SMS Primary Site Server = your Primary Site Server that has the packages, OK
- Select an existing Distribution Point, pick a Site Code, a DP, drag & drop the server name to the Packages Source List
- Select Destination of the new site
- Click “Assign Packages to DP”.
- This is the point where “waiting” begins; or the “go to bed and check on it in the morning” step!
Follow up the Next day
- The following day, check Package Status. For any packages that appear not to have worked, you may need to update all Distribution Points for that 1 package.
** Why are these optional? In our environment, if for some reason there is an “emergency” software installation which may need to occur before a Secondary can be fully rebuilt, the local technicians can browse to the smspkgx$ share, the folder, and manually install software. For that reason, we copy over the smspkgx$ folders, etc. As SMS unpacks the .pkg files into smspkgx$, the folders are replaced.