Len Paone

When in a Forest with one domain and several child domains. There will be one Central Service manager to support all domains. It means all CI's and WI's will be imported in one database. But the problem for us lies where we want each domain to have its own console and helpdesk team. For example: Helpdesk users from each domain can only see objects, incidents, activities, reports and etc from their own domain and not by other child domains. Also The main domain (root domain) will aggregate and hold all information. 1. Install a Primary site in you second domain. "Optional" 2. Does the machine name of the SCCM server have READ rights on the second domain? Usually, if you do have 2 way trusts, there shouldn't be an access issue. If not, apply rights. and setup the two-way trust. (without this, it will never work) 3.You can still put a secondary site at the Domain B location(s) but keep it a member of Domain A. There is no requirment that says it has to be a member of Domain B to be physically co-located with domain B. Install SCCM Client on Another Forest Trusted Domain There are few ways to perform the SCCM client installation in another trusted domain. For example, using start-up or login script, manual installation, and using client push method. Out of so many method, I would like to share something on the client push method. First of all, you are require to add the Server Locator Point (SLP) role in your SCCM server. Here is the: http://technet.microsoft.com/en-us/library/bb680672.aspx on how to create SLP in SCCM. Next, add the account that has domain admin rights on the another domain to the Client Push Installation account. Here is the http://technet.microsoft.com/en-us/library/bb680908.aspx on how to configure Client Push Installation account. After configured the Client Push Installation account, click on the Client tab. Enter the following to the installation properties, SMSSITECODE=XXX SMSSLP=SCCMSERVER.DOMAIN.COM Now, try right click the workstation name and select Install Client, go through the wizard to perform the installation.

First, you should ALWAYS use MDT for building and capturing the master images of Windows operating systems that you plan on deploying to computers in your environment. The main reason for this is that with MDT you can preconfigure the default user profile to customize the desktop of the user who will be using the computer you're deploying Windows onto. That's because with MDT you can configure user settings for the built-in Administrator account and then use the CopyProfile setting during deployment to make these the Default User settings on the target computer. Why does CopyProfile work with MDT but not with SCCM? Because during Lite Touch Installation (LTI) MDT runs its task sequence in the context of the built-in Administrator account while SCCM runs its task sequence in the context of the LocalSystem account. Now you could actually make CopyProfile work with SCCM deployments if you wanted to, but it takes a lot of painful scripting to do this, so why bother if MDT already does it so easily? There are some other reasons why you should use MDT and not SCCM for building and capturing your master images. For one thing, since SCCM is usually only deployed in a production environment, you don't really want to mess around there by building and capturing images and deploying them to test machines in your production environment. You should do your image building/testing in a safe test environment, not production, and most organizations won't want to go to the trouble of setting up a whole separate instance of SCCM just for testing purposes. Leverage that MDT 2010 Update 1 then copy the WIM files over to your deployment share. thisngs will go much smoother and you will have more control over the content of your base image with core apps installed. Remember best practices?