SCCM Accounts I can : Below are the accounts used in SCCM

1.       AMT Provisioning and Discovery Account

 

a.       Describes the function, creation, maintenance, and security best practices for the AMT Provisioning and Discovery Account.

 

2.       AMT Remote Admin Account

 

a.       Describes the function, creation, maintenance, and security best practices for the AMT Remote Admin Account.

 

3.       AMT User Accounts

 

a.       Describes the function, creation, maintenance, and security best practices for the AMT User Accounts.

 

4.       Capture Operating System Image Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Capture Operating System Image account.

 

5.       Client Push Installation Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Client Push Installation account.

 

6.       Health State Reference Publishing Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Health State Reference Publishing account.

 

7.       Health State Reference Querying Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Health State Reference Querying account.

 

8.       Management Point Database Connection Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Management Point Database Connection account.

 

9.       MEBx Account

 

a.       Describes the function, creation, maintenance, and security best practices for the MEBx Account.

 

10.   Multicast Service Point Connection Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Multicast Database Connection account.

 

11.   Network Access Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Network Access account.

 

12.   Package Access Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Package Access account.

 

13.   PXE Service Point Database Connection Account

 

a.       Describes the function, creation, maintenance, and security best practices for the PXE Service Point Database Connection account.

 

14.   RAS Sender Phone Book Account

 

a.       Describes the function, creation, maintenance, and security best practices for the RAS Sender Phone Book account.

 

15.   Remote Tools Permitted Viewer Accounts

 

a.       Describes the function, creation, maintenance, and security best practices for the Remote Tools Permitted Viewer accounts.

 

16.   Server Locator Point Database Connection Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Server Locator Point Database Connection account.

 

17.   Site Address Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Site Address account.

 

18.   Site System Installation Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Site System Installation account.

 

19.   Software Update Point Connection Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Software Update Point Connection account.

 

20.   Software Update Point Proxy Server Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Software Update Point Proxy Server account.

 

21.   Task Sequence Editor Domain Joining Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Task Sequence Editor Domain Joining account.

 

22.   Task Sequence Editor Network Folder Connection Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Task Sequence Editor Network Folder Connection account.

 

23.   Task Sequence Run As Account

 

a.       Describes the function, creation, maintenance, and security best practices for the Task Sequence Run As account.

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

LAB Setup

Hey below are the LAB Details to setup and meet the real time.

Total RAM Required is 6.2 GB + Base OS as 1 GB

 

 

 

 

--------------------------------------------------------------------------------------------------------------------------------
The above same posting as Excel work Book also

--------------------------------------------------------------------------------------------------------------------------------

 

	HYD Site Systems Details for easy config
OS	Role	RAM	System Name	IP address	Subnet Mask	Default Gateway	DNS Srv 1	DNS Srv 2
2008 R2	DC	256 MB	inhydtcs-dc01	10.0.0.1	255.255.0.0	10.0.0.100	10.0.0.1	172.0.0.1
2008 R2	Exchange	512 MB	inhydtcs-ex01	10.0.0.2	255.255.0.0	10.0.0.100	10.0.0.1	172.0.0.1
2008 R2	Central Site	700 MB	inhydtcs-cm01	10.0.0.3	255.255.0.0	10.0.0.100	10.0.0.1	172.0.0.1
2008 R2	Central SQL	700 MB	inhydtcs-sq01	10.0.0.4	255.255.0.0	10.0.0.100	10.0.0.1	172.0.0.1
2008 R2	Primary Site	1 GB	inhydtcs-cm02	10.0.0.5	255.255.0.0	10.0.0.100	10.0.0.1	172.0.0.1
XP	Client Xp1	128 MB	intcshyd-WS01	10.0.0.6	255.255.0.0	10.0.0.100	10.0.0.1	172.0.0.1
XP	Client 2	128 MB	intcshyd-WS02	10.0.0.7	255.255.0.0	10.0.0.100	10.0.0.1	172.0.0.1
windows 7	Client 3	512 MB	intcshyd-WS03	10.0.0.8	255.255.0.0	10.0.0.100	10.0.0.1	172.0.0.1
	BLR Site Systems Details for easy config
OS	Role		System Name	IP address	Subnet Mask	Default Gateway	DNS Srv 1	DNS Srv 2
2008 R2	ADC	256 MB	Inblrtcs-adc1	172.0.0.1	255.255.255.0.	172.0.0.100	172.0.0.1	10.0.0.1
2008 R2	Primary Site	1 GB	inblrtcs-cm03	172.0.0.2	255.255.255.0.	172.0.0.100	172.0.0.1	10.0.0.1
XP	Client Xp1	128 MB	intcsblr-WS01	172.0.0.3	255.255.255.0.	172.0.0.100	172.0.0.1	10.0.0.1
XP	Client 2	128 MB	intcsblr-WS02	172.0.0.4	255.255.255.0.	172.0.0.100	172.0.0.1	10.0.0.1
windows 7	Client 3	512 MB	intcsblr-WS03	172.0.0.5	255.255.255.0.	172.0.0.100	172.0.0.1	10.0.0.1
	Router Configuration Details - Should have two network cards
OS	Role		System Name	IP address	Subnet Mask	Default Gateway	DNS Srv 1	DNS Srv 2
Windows 2003	Router	200 MB	MHC-Router	10.0.0.100	255.255.0.0	N/A	172.0.0.1	10.0.0.1
				172.0.0.100	255.255.255.0.	N/A	172.0.0.1	10.0.0.1

enjoy,

1E Nomad Enterprise

Overview

Nomad Enterprise consists of two powerful components, Nomad Branch and PXE Lite.

Users with remote branches can benefit greatly from using Nomad for software distribution:

1. 1E Nomad delivers the ability for network booting, eliminating the need for an expensive server in each branch
2. 1E Nomad controls the amount of bandwidth it uses so even when bandwidth quite limited, remote users are still able to use the network during software distribution, and there is no need to considering adding expensive bandwidth resources.
3. Nomad is very cost effective but it can considerably reduce the number of servers in the network,

Nomad is a network optimization solution that uses patented technology to provide amazing levels of network efficiency. It improves network performance and enables server consolidation, allowing customers to get the most out of their existing networks and avoid costly network upgrades and the requirement for additional hardware.

Nomad Branch

Distributes systems management data once over the WAN and then shares it locally with peer agents. Can be used with, or without multicast.

PXE Lite

Provides network booting capabilities without the need for separate server hardware. Enables real zero-touch bare-metal OS deployments.

Reduce the cost of software deployment

Nomad Enterprise enables OS releases, software applications and updates to be distributed quickly and efficiently to remote server-less branch offices and to bandwidth-challenged environments. Nomad Enterprise ensures that software packages are only copied once over the WAN (Wide Area Network) to make the most efficient use of available network bandwidth. This eliminates the need for time consuming site visits or the presence of local servers at branches, delivering major cost savings for branch-oriented businesses, such as retail and banking.

Benefits at a glance:

Lower Cost

Distribution success for less cost

Reduces maintenance overhead

Reduces bandwidth needed

Maximizes Network Efficiency

Downloads once over the WAN

Dynamic throttling bandwidth control

Multicast implementation

Improves Reliability

Restart-able download

Consistency checking

Download subsequent changes

Increases Simplicity

Fewer servers required

Reuse existing skills

Seamless integration with SMS and ConfigMgr

Save on Hardware, Software Electricity

Eliminate the cost of a server in MOST branches

Less servers means less electricity

Less servers means less expensive software

What’s new in Nomad Branch 3.0?

Nomad Branch 3.0 now provides, central multicast, improved download reliability, has additional ConfigMgr integration and improved cache management features.

• Central multicast- Nomad Branch can distribute packages using multicast directly from a ConfigMgr/SMS Distribution Point. This benefits both central and branch distributions, minimizing the load on Distribution Points and significantly reducing WAN traffic.
• Additional Configuration Manager 2007 integration - Nomad Branch now supports OSD driver packages, alternate cache paths for Save and Restore Cache actions in Task Sequences and 64bit WinPE Save and Restore Cache actions.
• Enhanced download integrity- Nomad Branch now provides a per file checksum that enhances Nomad Branch capabilities in terms of efficiently recovering from transfer errors on a per file basis. The list of download file checksums is computed and made available centrally from the ConfigMgr/SMS Distribution Point thereby increasing efficiency.
• Download cache maintenance- Improvements to the Nomad Branch cache maintenance make it easier to manage Nomad Branch disk usage for its download cache.
• Internet based download throttling - Internet ConfigMgr clients can now use Nomad Branch 3.2 to download from a Distribution Point using HTTP/HTTPS. The package source will be downloaded once over the WAN and then shared locally with peer agents using the existing Nomad Branch methodology.
• Download monitoring interface - Nomad Branch provides a new download monitoring interface that also enables remote monitoring of machines.

Automate OS Deployments

1E’s experience leading hundreds of global Windows migrations has enabled us to create a comprehensive toolset that makes deploying new operating systems as simple as deploying software. Nomad Enterprise, complements the Microsoft Deployment Toolkit and provides effective software and OS transfer even in the largest, geographically dispersed organizations.

Consolidate Management Servers

Nomad Enterprise brings huge savings in terms of cost and effort by eliminating the need for secondary site servers. As only a few centrally located servers are needed, it is easier to implement the ConfigMgr/SMS hierarchy in these environments. Hardware costs are reduced significantly, as well as management costs as the environment is simpler to maintain.

Wan Optimization Using Multicast

For customers who wish to implement multicast for systems management data, Nomad Central Multicast provides the most bandwidth-efficient method of distributing large SMS/ConfigMgr files over a network. This patented technology reduces network traffic by simultaneously delivering a single stream of data to multiple PCs.

Using Central Multicast data is transferred from a Distribution Point (DP) to multiple subnets only once over each connection. This greatly reduces load on the DP and increases the number of subnets that it can service. It also reduces network traffic going across any intervening WAN links.

Local Multicast is ideally suited for environments with branch locations with over 100 PCs. It uses multicast to distribute locally, serving all PCs at once, and reduces LAN traffic and the load on branch PCs. As multicast is limited to the local subnet, no network infrastructure changes are required.

Learn more about 1E Nomad

OBT Info

Some use full links for OBT

http://www.google.com/search?q=out+of+band+management+sccm+2007&start=10&hl=en&sa=N&biw=1260&bih=620&prmd=ivnsfd&source=univ&tbm=vid&tbo=u&ei=QGbCTe7fO5SChQfdtpGyBQ&ved=0CDsQqwQ4Cg

http://communities.intel.com/community/openportit/vproexpert/microsoft-vpro/blog/2008/10/24/microsoft-sccm-2007-sp1-intel-vpro-training-videos-now-available

http://depsharee.blogspot.com/2011/03/my-configuration-manager-2007-out-of.html

www.vproexpert.com/playbook/vPro_SCCM_QuickStartGuide.pdf

http://64.4.11.252/en-us/library/cc161766.aspx

http://www.agileit.com/Blog/Lists/Posts/Post.aspx?Id=535

http://scug.be/blogs/sccm/archive/2010/05/06/step-by-step-guide-for-provisioning-intel-vpro-clients-in-sccm-2007-sp2-part-3.aspx

http://blogs.technet.com/b/configurationmgr/archive/2009/03/05/configmgr-2007-amt-vpro-useful-links-for-initial-planning-and-deployment.aspx

Powershell :- System Management Container

If you want to create Systems Management Server (SMS) 2003 or System Center Configuration Manager (ConfigMgr / SCCM) 2007, Container i.,e “System Management” with Power shell here it is the Cmdlts

 

 

# Get the distinguished name of the Active Directory domain
$DomainDn = ([adsi]"").distinguishedName
# Build distinguished name path of the System container
$SystemDn = "CN=System," + $DomainDn
# Retrieve a reference to the System container using the path we just built
$SysContainer = [adsi]"LDAP://$SystemDn"
# Create a new object inside the System container called System Management, of type "container"
$SysMgmtContainer = $SysContainer.Create("Container", "CN=System Management")
# Commit the new object to the Active Directory database
$SysMgmtContainer.SetInfo()

You’ll still have to set permissions appropriately, but if you’re looking to automate the entire process, here’s at least once piece!