Sherry Kissinger at myITforum.com

User AD Info - Ron Crumbaker Web Console 3.21

After seeing Hector's post, that reminded me I had added a similar button to Ron's console.  Either one will work.  If you notice that results returned from the original query take several seconds, you might want to try this one.  I noticed in my environment it was because the script needs to query every domain controller in order to determine last logged in time or last failed login time.  I added a prompt asking if they need that information returned.  Only if the tech wants that information will every DC be queried otherwise that section is skipped.

1. Copy machrest.asp elsewhere for paranoia
2. Edit MachRest.asp, near other button definitions (near the top) (but I suggest under the User Lookup button) add
   <input style="WIDTH: 180px" type="button" value="AD Info" name="Btnl735">
3. Add the contents of the attached .txt near the bottom; just after all of the other Sub / End Sub routines.

ConfigMgr 2007 Mof Snippets for extending Hardware Inventory

On www.sccmexpert.com, they have recently posted an update to the Individual MOF collection which was originally for SMS2003.  They've been updated to be ConfigMgr - friendly.  Go there, click on "The Mof", Mof Tools, then "Get the Scripts" (note; you may have to sign up on their web site--but it's quick & free).  Then grab "ConfigMgr MOF Snippets".

With SMS 2003 (and earlier), extending hardware inventory has been essentially the same; you add specifically crafted text to sms_def.mof on the server, and if data objects were needed, you "mofcomp'd" those data object text files on your clients.  With ConfigMgr 2007, it is just different enough to possibly be a little confusing.  I'll try to clear up any confusion.

In ConfigMgr 07, on the server in inboxes\clifiles.src\hinv, there are two mof files:  sms_def.mof and configuration.mof

You can of course leave them alone, but if you've 'extended hardware inventory' with SMS2003, or you've heard of doing this and want to do so, in a nutshell, in sms_def.mof if you were to add specifically crafted text to the bottom-- specifically the bits that make up the "Report" section, (the section with TRUE or FALSE in them), that would update the Hardware Inventory policy which your MPs offer to clients.  Once the clients pick up that from the MP, their next Hardware Inventory they'll try to report.

In configuration.mof at the bottom, you would add the bits that make up the "data" section.  I like to think of it as "telling the client how to report on what the policy is asking for".  For example, the Hardware Inventory policy may ask for McAfee AntiVirus information, because you just added that snippet to the bottom of sms_def.mof.  But a client won't know "how" to report on that custom data without instructions.  Configuration.mof is where you tell the client to pull that information from 'these specific registry keys'.

If you're just starting out with ConfigMgr, you can ignore these next 2 pieces of information... If you're a SMS2003 admin, just a couple things to help clear things up.  #1) Mofcomp.  Forget about it.  You know what I'm talking about!  Configuration.mof does all the work for you.  #2) In the snippets, you may notice a decided lack of a line you were used to seeing in the mof snippets for SMS2003, the #pragma namespace lines.  Since sms_def.mof is now only for cimv2/sms namespace, and configuration.mof is only for the cimv2 namespace, those lines to tell the mof "The next section is for this namespace" are just redundant and not needed.

Outlook 2003 - Locally saved .oft Organizational Forms Library forms cannot be opened

One way to replace the hardware for a Secondary Site

If you've got the political climate I do, where the corporate policy is to work on production server replacements during off hours, and that conflicts with your personal policy of "get to bed sometime before 1 am would be great", I've used this method for several Secondary Site hardware lease returns; my personal best time was 2.5 hours, but it usually takes me ~4 hrs (presuming all the 'prior to shipping hardware' tasks could be done ahead of time.  I've used this method extensively w/SMS2003, haven't had a chance to test it yet w/ConfigMgr.

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

MVP - 2008

I got an email (anxiously awaited for) that I've been awarded MVP status for another year.  I'm honored to be among such excellent company.  If you look at the list, most of them have written books, tools, or devote a good chunk of their lives to running a web site.