Archive for the ‘SMS/SCCM’ Category

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

October 17, 2008 Leave a comment

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.

Categories: SMS/SCCM

What is passive SUP for?

April 21, 2008 Leave a comment

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.




Categories: SMS/SCCM

SCCM across forests – one final note

April 15, 2008 Leave a comment


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.

Categories: SMS/SCCM

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

April 10, 2008 Leave a comment

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.

Categories: SMS/SCCM

SCCM distributed application is not monitored – SCOM 2007

April 7, 2008 Leave a comment


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

Categories: SMS/SCCM

deploying OS using SCCM to unknown computers

April 5, 2008 Leave a comment

Because people might want to know how, Michael Niehaus posted a great article about it here so visit it you will like it.

Categories: SMS/SCCM

Design SCCM in multiple forests – more notes

April 2, 2008 Leave a comment

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.



Categories: SMS/SCCM
%d bloggers like this: