Blog post: how to avoid importing the GUID into the new computer information

Here is a nice tip,

If you are importing the computer information to the SCCM for new client OS deployment you will find that you need to import the MAC and the GUID, the GUID is the hardest part, but to get rid of it, you can fill the GUID information with 1s and this will do the trick.

 

So the MAC address plus 1s in the GUID will make your life much easier J.

 

Cool one.

What is passive SUP for?

Long time I haven’t blogged sorry I was busy with some re-allocation to new place..etc

 

A nice discussion I have involved in about the benefit of having a passive SUP in the SCCM hierarchy, well NOTHING.

 

you do need to create a non active SUP to install the active Internet-based SUP (selected and configured in the Software Update Point Component Properties) and when creating an NLB for the active SUP.  The non active SUP would be installed on each server in the NLB and then the active SUP would be configured as the NLB.

 

Other than this, you cannot use it for reporting. I thought that clients in branch sites can report to the local WSUS and this info will be replicated to the parent WSUS somehow, well this is wrong. So if you will not deploy a WSUS you don’t need passive SUPs.

 

Regards,

Mahmoud.

SCCM across forests – one final note

Hello,

One final note regarding this topic, if you will install SCCM site in different forest, Microsoft doesn’t support installing the secondary site in the new forest,  you will have to install a child site only on the new site. So all the planning has to be done base on child site planning.

PXE boot creates a new record for computers after reinstalling the OS using PXE

Hi,
I spent this week trying to understand this issue from a lot of SCCM folks, thanks god I finally got it, so I would like to share it with you:

When you take a laptop, PXE boots it and drops an image onto it. ConfigMgr client installs and laptop joins site and applies packages – cool! Now then you clear PXE advertisement and roll out an OS onto that system again. There has been no change at all on the laptop so all the BIOS GUIDS etc. are identical, however a new ConfigMgr resource record and a new ConfigMgr GUID is assigned to the machine. The machine maintains its domain SID, MAC address, SMBIOS GUID etc. so why SCCM is creating the a new records:

This is the default behavior If site in mixed mode, and manually resolve conflicts is not enabled, the rebuilt machine gets new sccm identity (guid). If the site setting to manually resolve conflicts is enabled, then those records would appear in the resolve conflicts node. If in native mode this should not occur.

The basic problem is that when a computer is re-imaged from bare-metal in mixed mode security, ConfigMgr has no way to know if it’s really the same computer and you want it to have the same identity, or whether it is some rogue computer trying to usurp the identity of an already managed computer. PXE is a very insecure protocol, and things like the MAC address and SMBIOS are easily spoofed.




The “Manually resolving conflicting records” option is a site-wide setting, but if you set it, it requires IT Admin intervention to resolve the conflict. The current behavior is not considered to be a bug, though arguably we should offer an “automatically merge” option that doesn’t require IT Admin intervention

In native mode you don’t have this issue because of the certificates, In native mode, essentially SCCM punted the problem off to whomever (or whatever) is issuing the certificates. If the certificate issuer thinks it’s the same computer, then the new issued certificate should have the same subject name and #2 under Native Mode Security in the slide below applies. If the certificate issuer doesn’t think it’s the same computer or doesn’t know, then the new issued certificate should have a different subject name and #3 under Native Mode Security applies.

But How the certificate issuer knows that the computer is old is new one then?

Could be by a wide spectrum of different ways, depending on how certain the certificate issuer wants to be that it really is the same computer and not some rogue.

At the least secure, but most automatic, end of the spectrum, the certificate could be issued by AD automatically for any computer joining the domain, with the subject name set of the FQDN of the computer. In this case, if the computer runs an OS deployment task sequence, it will be able to join the domain (since the task sequence has the domain join credentials) and it will automatically get a certificate from AD without the IT Admin doing anything. Obviously, this isn’t very secure.

At the other end of the spectrum, and IT Admin might have to physical visit the computer, verify its identity, and install the certificate from removable media once he has verified the identity of the computer. This is the most secure approach, but the hardest because of the manual steps required.

Any given customer will have to decide what approach meets their needs on the security/ease-of-use tradeoff.

In the case of PXE boot, the MAC address of the computer and/or the SMBIOS UUID of the computer are matched against entries in the ConfigMgr database. Assuming that a matching entry is found, the computer name from the database entry is sent back to the computer running the task sequence and that computer name is assigned, this is how SCCM recognize the machine in the case of PXE where not certificate is installed on the machine the machine is wiped off.

SCCM distributed application is not monitored – SCOM 2007

Hi,

Here is some tips for people who cannot monitor SCCM using the latest SCOM management pack:

–          Make sure the agent proxy is enabled on the SCCM server.

–          Make sure that you have created  SMS_INSTALL_DIR_PATH system variable.

–          Make sure that you installed the SCOM x86 agent, you cannot monitor SCCM using the x64 agent, this is a known issue, so you might need to install the agent manually.

I am pretty sure that the SCCM distributed application will be monitored now J

deploying OS using SCCM to unknown computers

Because people might want to know how, Michael Niehaus posted a great article about it here http://blogs.technet.com/mniehaus/archive/2008/01/19/microsoft-deployment-configmgr-boot-media-unknown-computers-web-services.aspx so visit it you will like it.

Design SCCM in multiple forests – more notes

This is will grow and grow, but here we go:

You don’t need to have native mode across the forests to be able to manage the other forests, as long as each forest as its own site. If you have single site that covers the 2 forest you will need SCCM in native mode.

 

If you have any questions please post a comment on any of my blog entries.

 

Bye.

Design SCCM in multiple forests – notes

Hi All,

I have some notes on my previous post here they are:

–          If you use 2 way forest trust between the forests, then SCCM can use the SCCM machine account in the sender configuration, so you don’t need to create an account, this is a note as I stated that there is must be a trust between forests

–          If you don’t have a trust, then the account used could be a local account, so the trust is not required to configure SCCM across forests.

 

C ya

SCCM updates deployment : : unable to evaluate assignment

Last week I was deploying an SCCM SW update feature, I did it before a lot of times so I thought I was easy, I did everything, deployment template, package, update list, WSUS gpo, everything, and deployed a security hotfix to a test server and oops. It won’t get deployed.

 

Some logging revealed the following warning message at the client updatesdeployment.log unable to evaluate assignment GUID as it is not activated yet

 

I spent 2 hours trying to figure out the problem, then went to launch J, spending other 2 hours at launch J. Then get back to find that the update is deployed, at first glance I thought it was related to the GPO settings as it was scheduled to run at 3 AM and the update deployed at 3 PM exactly so I thought was something is going on.

 

After some advises from the great SCCM people, I found that the deployment plan is configured to run at UTC time, since I had + 4 hours ahead UtC and I created the package at 11 am it get deployed at 3 PM J.

 

So to force the update to occur at the specified time you have to make sure that the schedule is set to the local client time, or make sure to calculate the UTC + and -.

 

Next week I will be deploying SCOM SP1, so we will talk a lot about SCOM… c ya

Design SCCM 2007 in multiple forests deployment

• I have collected this from here and there, I had the chance to plan a deployment in 4 forest network, SCCM was deployed in central forest, and clients will be distribute across other 3, so I decided to go with mixed mode secondary site in each forest, so here is the design/configuration notes:
• 1.1 External Forests Design:
• Deploying Configuration Manager 2007 across multiple Active Directory forests, plan for the following considerations when designing your Configuration Manager 2007 hierarchy:
• · Communications within a Configuration Manager 2007 site
• · Communications between Configuration Manager 2007 sites
• · Support for clients across forests
• · Configuring clients across Active Directory forests
• · Approving clients (mixed mode) across Active Directory forests
• · Roaming support across Active Directory forests
• · Cross-Forest Communications between Configuration Manager Sites
• Data is sent between sites in a Configuration Manager 2007 hierarchy to enable central administration within a distributed model. For example, advertisements and packages flow down from a primary site to a child primary site, and inventory data from child primary sites are sent up to the central primary site. This information is sent between site servers in the hierarchy when the site communicates with a parent or child site. Data sent between sites is signed by default, and because sites in different Active Directory forests cannot automatically retrieve keys from Active Directory, manual key exchange using the hierarchy maintenance tool (Preinst.exe) is required to configure inter-site communication.
• When one or more sites in the Configuration Manager 2007 hierarchy reside within a different Active Directory forest, Windows user accounts has to be configured to act as addresses for site-to-site communications except in the following scenario:
• Important
• All Active Directory forests are configured for the forest functional level of Windows Server 2003 and have a two-way forest trust
• The same design concept applied to branch offices will be applied to forests, it is recommended to have a secondary site in each forest with clients less than 200 and child sites for client with more than 200 clients.
• Note
• Distribution point cannot be installed by itself in remote forest.
• 1.1.1 Client assignment in multiple forests:
• If the clients will not roam from one forest to another during the assignment process, then you can extend the AD schema in your new forest and the clients in this forest will find their site and assign successfully (on the assumption that they all domain-joined and not workgroup computers). If the clients are the network in the original forest during assignment, this won’t work – they will need to obtain site information from a SLP.
• Once assigned, clients in the second forest then need to find their default management point. If they are on the second forest network and the schema is extended, they will find their default management point from AD. However, if they are on the original forest network, locating the default management point via AD will probably fail (although I’m not 100% sure of this – could they locate a GC server in their own forest?), and they will need an alternative mechanism – which could be DNS, or SLP, or WINS.
• For the clients in order to be assigned the following must be configured correctly:
• · Boundaries must not overlap between sites.
• · Extended AD in each forest.
• · Make sure that you have a SLP for the hierarchy (central site) and that clients can locate as their backup mechanism for service location (easiest way is to assign it during client installation)
• · Make sure that DNS resolves all server names between the different namespaces (eg forwarders, stub zones, or root hints)
• · Configure DNS publishing for the default management point, and specify the DNS suffix for the client during installation
• With this combination, clients will try to use their local AD for site assignment and locating a management point. If this fails, they will use the SLP for site assignment, and DNS for locating the management point.
• 1.1.2 Accounts and Security requirements:
• In order to allow the communication between sites in different forest the following criteria has to be met:
• · All Active Directory forests are configured for the forest functional level of Windows Server 2003 and have a two-way forest trust.
• · Sender address accounts to use domain user accounts that are valid within the target forest to enable site-to-site communication.
• · The sender account has to be local administrator on each server with child site role installed.