Replace the Hardware for a Secondary Site

One way to replace the hardware for a Secondary Site

from Sherry ==> http://myitforum.com/cs2/blogs/skissinger/archive/2008/07/09/one-way-to-replace-the-hardware-for-a-secondary-site.aspx

Tools needed:

1. Preinst.exe from SMS 2003 Toolkit 2 http://www.microsoft.com/smserver/downloads/2003/tools/toolkit.mspx

2. PreLoadPkgonSite also from SMS 2003 Toolkit 2

3. CloneDP, installed (pre-req of .Net 2) http://sourceforge.net/projects/smsclonedp/

4. Script or method to enumerate .pkg files in X:\smspkg

5. MPTroubleshooter also from SMS2003 Toolkit 2

Resources needed locally on the new server:

1. SMS 2003 Setup files

2. If secondary is to be a proxy MP, setup files for the Operating System

3. Restored or copied from old server, X:\smspkg

4. 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

1. Tasks that can done before the new hardware is shipped to the destination; but could also be done once hardware arrives at new location.

2. Tasks done after the new hardware has arrived.

3. Work done after SMS 2003 reinstalled

4. Follow up the next day.

Prior to shipping hardware

1. From a local Distribution Point, copy \\otherserver\x$\smspkg to x:\smspkg

2. From a local Distribution Point, copy \\otherserver\x$\smspkgx$ to x:\smspkgx$ **

3. Copy SMS 2003 setup files to x:\SMSTools\setup

4. Copy PreloadPkgonSite.exe to x:\SMSTools

5. 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

1. 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.

2. On Current Server, Disable the SMS Services so they do not launch automatically following a reboot.

3. Rename current Server to ServerName_OLD, change IP address from static to dhcp. Reboot.

4. On new hardware, rename to ServerName, change IP from dhcp to static. Reboot.

5. 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.

6. 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. (http://www.myitforum.com/articles/1/view.asp?id=5355)

7. Remove the SMS entries for the server in Active Directory for the server itself, and for the MP record. (in the OU System\System Management, SMS-Site-xxx, and SMS-MP-xxx-ServerName)
   

8. At the Primary Site(s), remove the Standard Sender Address for the secondary site.  Wait a minute or so.

9. At the Primary Sites(s), create a new Standard Sender Address for the secondary site.
   

10. At the secondary site, unshare smspkge$ & rename to smspkge_old (you’ll move files later)**

11. At the secondary site, install SMS from smstools\...\setup.exe, Advanced Security, Remote Tools enabled.

12. Monitor sms\logs\*.log files for errors

13. Monitor Active Directory Users and Computers, the OU System/System Management, for SMS-Site-Rxx to appear.

14. 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.

15. At the secondary site, monitor sms\logs\mpsetup.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

1. Push down 1 (smallish) package. Monitor the Secondary Site recreating smspkge$ share, and putting the new package in there.

2. 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). **

3. At the secondary, go to a command prompt. CD to x:\smspkg Pick 1 package. Type in x:\smstools\preloadpkgonsite PackageID (without the .pkg extension, i.e., x:\smstools\preloadpkgonsite TST00012)

4. 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.

5. Following the success message, monitor distmgr.log on the Secondary to confirm that package's info has been sent.

6. At the Central Site, add the (new) Secondary site distribution point to that 1 package.

7. Monitor Sender.log at the server(s). Monitor Package Status at the Primary Site server(s).

8. 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.

9. 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:\smstools\preloadbuild.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:\smspkg\preload.bat",True)
   For each file in fc
   TheArray = Split(file,"\", -1, 1)
   StrNameToLoad = Left(TheArray(2),8)
   theFile.writeline "e:\smstools\preloadpkgonsite " & strNameToLoad & " >> e:\smstools\preload1.txt"
   next
   TheFile.Close

10. Now that you have a e:\smspkg\preload.bat, go to a cmd prompt, and switch to e:\smspkg. Type in preload.bat, and wait.

11. When it is done, open up e:\smstools\preload1.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.

12. 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).

13. 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.

14. 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

1. Launch

2. SMS Primary Site Server = your Primary Site Server that has the packages, OK

3. Select an existing Distribution Point, pick a Site Code, a DP, drag & drop the server name to the Packages Source List

4. Select Destination of the new site

5. Click “Assign Packages to DP”.

6. 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

1. 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.

Distribution Point Update Vs Refresh

Choose Between Updating and Refreshing a Package

Applies To: System Center Configuration Manager 2007 only

Updating and refreshing Microsoft System Center Configuration Manager 2007 packages are two different operations. Use the following table to help decide when to update and when to refresh a package.

 

Criterion	Package Update	Package Refresh
Use when	You make a modification to the package source, such as adding, changing, or deleting a file or folder.	You need to repair a package at a specific distribution point.
What it does	Builds a new, complete, compressed package file and a delta compressed package file from the updated package source files. The delta file is passed to all distribution points.	Recopies the compressed package from the local site server to the distribution point but does not copy files from the package source.
Resets access control list (ACL)?	No.	Yes, if you have made changes to the Package Access Accounts.
Resets the Virtual Directory?	Yes, if you have enabled or disabled BITS on the distribution point since the last package update.	Yes, if you have enabled or disabled BITS on the distribution point since the last package refresh.
Updates the package source version?	Yes.	No.
Increments package version in client policy?	Yes.	No.

Manage DP wizard ==>using Refresh the package?--Delete and recreate the package ,does not change source version.

right click Update ==>Distribution Point -Change source version and copy the changed source.(Delta change)

 

 

more ==>http://technet.microsoft.com/en-us/library/bb892806.aspx

Difference between Update and Refresh for DPs

 

1) Update distribution points increments the package version, goes to the source location, constructs new package content but only sends the delta between what is already present on the DP and what is currently in the new package source. Also this action is package specific and once you trigger this action all the DPs to which the package has been distributed will get the new version.

this option best when all DP’s are in local

2) Refresh distribution points does not increment the package version but simply sends out the current version of the package content again to a specific DP. So this is action is specific to a package-DP association and should be used when the content on any particular DP appears corrupted.
Impact of enabling BDR:

1) For Update Distribution Points: Consider the scenario where one (or potentially several) files in the package source has been updated/modified. Enabling BDR would trigger distribution manager to do a diff between the current version of the file and the new version of the file and only send the delta changes within the file. On the receiving side we will then perform a BDR merge for that delta. So in the BDR case we may end up sending lesser data than in the scenario where BDR is not enabled on the package.

2) For Refresh Distribution Points: BDR setting has no affect - we simply send the entire current version of the package.

Configuring SCCM and Branch Cache

Configuring SCCM and Branch Cache

Branch cache is a feature introduced with Windows 2008 R2 that allows systems within the same subnet and separated from a content source (such as a WSUS server) to share downloaded content locally rather than each system having to traverse a latent network link back to the content source. Branch cache has two modes of operation – distributed cache mode and hosted cache mode. SCCM only supports distributed cache mode.
As mentioned, branch cache is a function of the OS and not of SCCM but, with the release of SCCM SP2, we now are able to leverage branch cache on enabled servers. When we find branch cache enabled we use it – there is no special SCCM configuration requirements for branch cache other than what is likely in se in most environments anyway. We will highlight those shortly but to start a diagram of a sample configuration might help explain how this is all setup.

In the diagram we have 4 systems. The SCCM SP2 site server, an SCCM distribution point being hosted on a Windows 2008 R2 server that has branch cache enabled and two client systems – one server and one workstation. We have mentioned already that to support branch cache we need to use a Windows 2008 R2 system – but what about clients? From the diagram note that branch cache is supported natively on Windows 2008 R2 and Windows 7 – and with the addition of BITS 4.0 clients can also take advantage of branch cache on Vista SP1 and Windows 2008 SP1/SP2.
The diagram shows how SCCM works with branch cache. The first time content is requested from the distribution point the client has no choice but to retrieve it across the latent network. Once retrieved the content is stored by branch cache. When the second client attempts to retrieve the content it detects a latent network and sends out a request for any peers with the content. The first client responds and serves up the content thus avoiding the need to pull it across from the distribution point.
OK, so we have the general concept of how it works – so how do we set it up? It’s fairly easy. First, what are the requirements in SCCM to make use of branch cache. We need our distribution point to be installed on Windows 2008 R2 and to be BITS enabled.

The only other requirement is that your advertisement be set to download and execute locally.

Both of these settings are common in most environments and are all that is required on the SCCM side. There is no selection in SCCM to ‘enable’ branch cache – with the settings above it just happens.
So how do we configure branch cache on the OS side? Just a few settings to configure. First we need to enable branch cache – let’s start with the distribution point. In Server Manager, select features and add the branch cache feature. There is no configuration here – the feature is either on or off. Once installed you will see it in the feature list.

Next, we have to configure branch cache on our clients. This can be done through local policy on each system or – much easier – through domain policy. On my domain controller I open the group policy management console. In my lab I created an OU for just the systems I want to enable for branch cache and I created a GPO to enable branch cache.

Editing the properties of the GPO we have two places to configure. First, is branch cache policy. Here we enable branch cache, set distributed cache mode, define the speed that we consider to be a latent network (default 80 ms) and configure the percentage of disk space to allocate to branch cache activity.

Note that the one option we did not configure was to enable hosted cache mode. Why? Remember, SCCM only supports distributed cache mode so, for SCCM, there is no need to enabled hosted cache mode.
A word about hosted cache mode. The OS documentation that discusses branch cache discusses both modes of operation and discuses steos to configure SMB file transfers through branch cache. To me, the documentation is a bit fuzz. From what I can tell, configuring branch cache to support SMB requires some additional configuration on the content server – such as enabling a role service called ‘branch cache for network files’ and configuring specific shares to support branch cache using the ‘share and storage management tool’. Since SCCM uses branch cache via BITS there is no need to do this additional configuration to support SMB.
In addition to the above we must configure the windows firewall to allow branch cache specific communication as follows:

Both the inbound and outbound firewall rules are accessible on the predefined list – so configuring them is as easy as selecting from the drop down menu when configuring a new rule.

OK, so all of this is configured – how do we know if it’s working? To test, I setup a package and advertisement. When testing it’s important to understand that once the package is downloaded and cached, you have to either modify the content or setup a new package because unless there is a change, clients will always pull the content from the cache after the first download due to the latent network conditions.
For the test, I start with a fresh package. The client that will download the content first will have to go to the distribution point – nothing will come from the cache since no content has yet been downloaded.

With all of this I’m ready to start the download but to simulate a latent network in my lab I must first start a tool that will ‘inject’ latency into the network connection between the distribution point and my first client. I’ll use a tool we have internally to introduce a 30 ms latency – I will maintain this latency throughout my testing. Note that my policy settings above consider any network more latent than 20 ms to be slow.

With all of this configured, I start my advertisement which initiates a download of content.

At the end of the download I run the advertisement and then move on to my second machine. This second machine is where we expect to see branch cache in action.
I prepare to run the same advertisement on the second machine – note you can tell that this advertisement has never been run before on my system – which is important when testing branch cache.

I’m about to hit run but how can I tell whether branch cache actually fires up? Performance monitor. With performance monitor you can determine whether content is being transferred from the local branch cache or from a branch cache partner vs. the network. The chart below shows a chart of perfmon counters that you get from the branch cache object. The two most interesting are the Bytes from cache and Bytes from server. If content is being retrieved from either a systems local branch cache or a peer systems branch cache, that counter will show activity. In our test case and on the second system, no content for this advertisement has ever been downloaded before so we expect content to be retrieved from our peer client that is branch cache enabled.

We initiate the advertisement as before and downloading begins.
We allow the download to finish, complete the advertisement and then look back at our performance counter numbers to see what happened.
By looking at our counters we can see that we did pull the content from our peer caching partner – so branch cache worked.
Another way we can tell that our package came over from branch cache is by looking in the event log on the system as show below. Look for event 60 and on the detail tab look for the peerProtocolFlags value. If it is set to 1 then branch cache was used to deliver the content. Thanks to my colleague Frank for the tip!

Branch cache is just one more option available to administrators to help deliver content to clients efficiently and reduce load on the network. It’s not difficult to setup and offers notable performance advantage – defiantly worth taking a look.

DP Pros and Cons

BDP PROS:

· Content on demand

· Uses bits to get content

BDP CONS:

· SCCM client breaks so does the DP

· Requires an unprotected DP to get content

· Less robust reporting than a secondary site.

DP PROS:

· Senders

· Better reporting

· No need for unprotected parent DP

DP CONS:

· No content on demand

· Uses SMB to get content