When designing a new ConfigMgr environment, there is not only a total design needed but also a plan for the collections. I let my decision mostly be based on what functionality is needed, and if Active Directory is leading or not. This because you can create collections on many different ways, and advertisements can only be set on collections. So when you advertise an operating system, application or software update it will be bound to a collection. For OS deployment you can create additional colllections, but what to do with the other ones? The most used way is bound the collections to Active Directory OU's. In that way Active Directory is leading, and it will synchronize objects to ConfigMgr collections. I will explain here what to do, and how to bind them to Active Directory.
Sooner then expected, but even a long wait: ConfigMgr 2007 R3 is here! This will be probably the last release for ConfigMgr 2007, because the next release is now available in beta. Which improvements will R3 bring to us, and is it worth it for installing the update? The answer is Yes, because there are some cool things in this release. Below is a quick summary of what’s new with R3:
One of the difficult things in deployment is getting all drivers to work. Best practice here is to remove the "auto-apply drivers" in the Task sequence, and put "add driver package" instead. Most of the time when i'm import drivers, i give them a tag-name for the model. In that way you can easely update or remove a model later. There is also an option for creating folders in it. Bad thing is you can't import a driver multiple times, so that's not a good idea after all. Also the search folder will be a good idea actually.. In that way the folders are query based, so you can seperate the drivers in different folders.
