Today I installed ConfigMgr 2012 Beta 2 again with my PQR collegue Stephan Wibier. Now also the default configuration (Administration) is done, for getting new functionality to work. This installation will be used to manage the virtual (www.virtuall.eu) environment, and will also be used for Patch management. We have seen many new functionalities today! Till now they are all improvements!
First I have added Domain Admins in Administrative Users, so my other PQR collegues can also make use of the new ConfigMgr functionality! Now let's start to configure ConfigMgr 2012 B2! First I go to Discovery Methods. New in here is "Active Directory Forest Discovery". When enabling this feature there are two (2) checkboxes. These will be automatically add the boundaries for you! Now is that handy or not?
When enabling other Discovery Methods (for example: Active Directory Security Group, System or System Group discovery) a full discovery will be run automatically. Also "Enable delta discovery" is enabled by default now. The only discovery method enabled by default (after a fresh installation) is the Heartbeat Discovery. The new items will soon be displayed in the collections.
After this collections will be filled beneath "Assets and Compliance". There are now less collections then ConfigMgr 2007. Things are organized better now! There will be default collections for Users, Devices, User Collections and Device Collections. Beneath User and Device Collections are the additional collections. These will be displayed for make it clearer.
New User collections are:
New Device collections are:
The console performance is must better then before! This because it's running in Silverlight now. Functionality in the ConfigMgr console is found on a logical place now. No searching for options anymore, but just find it quick and easy with the new ribbon! In every step in the ConfigMgr console, the ribbon is available! No/less right clicking anymore..
This is functioning all well, what a great product/upgrade this is! Also the different tabs (also found in other Microsoft products) are in place now: Administration, Software Library, Monitoring & Assets and Compliance.
More soon!
When installing ConfigMgr 2007 on a clustered SQL Server Instance, specific configuration is needed. Then preparing for a ConfigMgr installation must happen on all servers which are part of the SQL cluster. How that works I will explain in this blog. Because it's not always usual to install ConfigMgr on a clustered SQL Server Instance, remember to follow these steps!
First open this TechNet article: How to Install Configuration Manager Using a Clustered SQL Server Instance, which can be found on http://technet.microsoft.com/en-us/library/bb680513.aspx
The steps which are needed:
- Create the virtual SQL Server cluster to host the site database on an existing Windows Server cluster environment.
- Add the machine account of the primary site server machine to the Local Administrators group of each Windows Server cluster node computer. This is required to allow the site server to install and configure settings later.
- In the virtual SQL Server instance, assign the sysadmin SQL Server role to the user account running Configuration Manager Setup.
- Start Configuration Manager Setup, and select to install Configuration Manager using custom settings.
- On the Configuration Manager Database Server page of the Configuration Manager Setup Wizard, enter the name of the clustered virtual SQL Server instance to host the site database and the name for the site database to be created on that instance by setup.
Important: During setup, you must enter the name of the virtual SQL Server cluster instance, and not the virtual Windows Server name created by the Windows Server cluster. Installing the site database using the Windows Server cluster virtual instance name will result in the site database being installed on the local hard drive of the active Windows Server cluster node, and it will prevent successful failover if that node fails.
Also have a look at "To verify that the site database was installed successfully", to check if installation was done right!
But what to do when things goes wrong?
The following errors can be shown:
SQL Server sysadmin rights: Either the user account running Configuration Manager Setup does not have sysadmin SQL Server role permissions on the SQL Server instance targeted for site database installation or the SQL Server instance could not be contacted to verify permissions. Setup cannot continue.
SMS Provider Communication: A communication error has been detected between the SMS Provider computer and the site database computer. This error can occur when the site database server is offline or if a valid SPN has not been registered in Active Directory Domain Services for the SQL Server instance hosting the site database. Setup cannot continue.
When this errors are seen during setup (or during prerequisite check), check the following steps:
- Is the machine account of the primary site server added to the Local Administrators group of each Windows Server cluster node computer?
- Is the virtual SQL Server instance, with the sysadmin SQL Server role assigned to the user account running Configuration Manager Setup?
- Is the name of the virtual SQL Server cluster instance entered during setup? (format: SQL Server cluster name\Instance name)
The solution was found with configuring the clustered SQL Server Instance right:
- The Service Pack level from the clustered SQL Server and the new Instance created must be on the same level.
- Because the new Instance must be installed on each Windows Server cluster node computer, make sure the installation (database/log) paths are same on each node.
- Make sure permissions are set right on the clustered SQL Server Instance. (double check)
This can also be validated using "ODBC Data Source Administrator". Choose the System DSN tab, and add the clustered SQL Server Instance. This because it has nothing to do with ConfigMgr, but all with SQL Server configuration.
I hope this information will be useful for future installations!
On 23 march 2011 during MMS 2011 in Las Vegas, ConfigMgr 2012 Beta 2 is released. Because I'm doing ConfigMgr implementations most of times, I want to know which changes are made during installation. In this blog the setup of this new release is viewed, to see if there are any differences between previous releases. This installation is done on a Windows Server 2008 R2 Enterprise x64 server.
Let's download first the new Beta release "ConfigMgr_2012_Beta2_ENU_7561" on Technet Downloads: http://technet.microsoft.com/en-us/bb403698
Unpack the file, and start Splash.hta for starting the setup. The following screen will be seen then, which has many new options in it:
When choosing INSTALL a message is displayed that DotNet Framework 3.5 SP1 and 4.0 are needed for starting the installation. So let's see first what's needed on the server for having a successful installation:
- DotNet Framework 3.5 SP1 and 4.0 (with default IIS Role Services)
- SQL Server 2008 SP1 with Cumulative Update 10 or higher (SP2 and R2 are not supported yet)
- Remote Differential Compression (RDC)
- Background Intelligence Transfer Service (BITS)
- Windows Server Updates Servies (WSUS) > (optional)
- IIS Role Services > IIS 6 WMI Compatibility
Then the installation begins..
Next in line after this screen are:
- Available Setup Options (Primary Site Server, Central Administration Site, Recover a Site Server)
- Microsoft Software License Terms
- Updated Prerequisite Components (14 items till now)
- Site and Installation Settings (Site Code, Site Name)
- Primary Site Installation (install a standalone site, or join an existing hierarchy)
- Database Server (SQL Server 2008 SP1 with cumulative update 10 is needed)
When this error message is displayed after installing SQL Server 2008 SP1 with cumulative update 10, the TCP/IP protocol must be enabled.
Start "SQL Server Configuration Manager" for that, choose Protocols, and enable TCP/IP. Then restart SQL Server service for make changes active.
Now the installation can be continued:
- SMS Provider Settings (cannot be installed on a clustered SQL server)
- Client Computer Communication Settings (Native or Mixed mode)
- Site System Roles (Choose HTTP or HTTPS for MP or DP, this can be choosen per rol)
- Customer Experience Improvement Program Configuration
- Setting Summary
- Prerequisite Check
- Install.. (this takes a while..)
After that ConfigMgr 2012 Beta 2 is installed! Not that hard I think?
Next blog will zoom deeper in configuring this new ConfigMgr release! I'm very excited about this new ConfigMgr release! I hope you are too!
Thanks to my PQR collegue Stephan Wibier, for the SQL (TCP/IP protocol) advise!
With ConfigMgr 2007 there can be put many information in the Task Sequence used for OSD. With Windows XP, Vista or 7 there will be different files created for using a unattend installation. All information set in the Task Sequence will be used for creating that specific file. Only a dynamically computername is missing here! How to assign a dynamic computername during OSD, that's the question!
In a Task Sequence used for OSD, this information can be placed in "Apply Windows Settings" and "Apply Network Settings". In "Apply Windows Settings" the following information is (most of times) set:
- User/Organization name
- Product key
- Local administrator password
- Time zone
In "Apply Network Settings" the following information is (most of times) set:
- Join a workgroup or domain
- Set specific domain information
- Account used for domain join
With this information a sysprep.inf file (for Windows XP) or a unattend.xml file (for Windows Vista or 7) is created at specific places. The sysprep.inf file will be created/placed at C:\Sysprep (with the deployment tools). The unattend.xml will be created/placed at C:\Windows\Panther\Unattend. Sysprep is already build-in for Windows Vista and 7.
During above steps ("Apply Windows Settings" and "Apply Network Settings") these files will be generated. During "Setup windows and ConfigMgr" these files will be used for having a unattend installation. The only information missing here is how to set the computername?
With MDT integration an additional step is used for making that possible. Then a Task Sequence variable can be used for dynamically assigning a computername. This is explained here: http://blog.coretech.dk/mip/wrong-pc-name-after-deployment/
With ConfigMgr only (without MDT integration) an additional script is needed for unattended installation, or the computername must be filled-in manually during OSD (not recommended). The additional script must have lines in it for recognizing the computername in the BIOS, and place that information in the sysprep.inf or unattend.xml file.
Most of times I disable both "Apply Windows Settings" and "Apply Network Settings" steps in the Task Sequence, and making use of the sysprep.inf and/or unattend.xml which is created by ConfigMgr during OSD. The only change I make then is to replace the Computername with an "*" sign, and create a separate package from this file.
Then I put that file (as package) at the "Apply Operating System" step. The package which contains the script (converted to executable) is put in an additional step, in this case: "Assettag To Unattend". The script I use is as follows (using the Asset Tag as computername):
Windows XP on HP devices:
#include <WinAPI.au3>
#include <WindowsConstants.au3>
#include <File.au3>
#include <Array.au3>
RunWait("cmd.exe /c " & "wmic /node:localhost systemenclosure get smbiosassettag > c:\sysprep\assettag.txt", "",@SW_HIDE)
$file = FileOpen("C:\sysprep\assettag.txt", 0)
$assettag = FileReadLine($file,2)
FileClose($file)
ReplaceInFile('C:\sysprep\sysprep.inf', "*", $assettag)
Func ReplaceInFile($io_file, $io_word, $io_replacement)
Dim $Records
$Lines = _FileCountLines($io_File)
If Not _FileReadToArray($io_file, $Records) Then
ConsoleWriteError("There was an error reading > " & $io_file & @CRLF)
Exit
ElseIf _FileReadToArray($io_file, $Records) == "" Then
ConsoleWriteError("File is empty!" & @CRLF)
ElseIf Not @error Then
ConsoleWrite("> File succeeded!" & @CRLF)
EndIf
$File = FileOpen($io_file, 2)
For $ax = 1 To $Records[0]
ConsoleWrite("+> " & $Records[$ax] & @CRLF)
$Replace = StringReplace($Records[$ax], $io_word, $io_replacement)
ConsoleWrite("+> " & $Replace & @CRLF)
If _FileCountLines($io_file) < UBound($Lines) - 1 Then
FileWrite($File, $Replace & @CRLF)
Else
FileWrite($File, $Replace & @CRLF)
EndIf
Next
FileClose($File)
EndFunc
Windows XP on Dell devices:
Replace "systemenclosure get smbiosassettag" with
"systemenclosure get serialnumber". Then it works also on Dell devices.
Windows Vista or 7 on HP devices:
#include <WinAPI.au3>
#include <WindowsConstants.au3>
#include <File.au3>
#include <Array.au3>
RunWait("cmd.exe /c " & "wmic /node:localhost systemenclosure get smbiosassettag > c:\_SMSTaskSequence\assettag.txt", "",@SW_HIDE)
$file = FileOpen("C:\_SMSTaskSequence\assettag.txt", 0)
$assettag = FileReadLine($file,2)
FileClose($file)
ReplaceInFile('C:\Windows\Panther\unattend\unattend.xml', "*", StringStripWS ($assettag,8))
Func ReplaceInFile($io_file, $io_word, $io_replacement)
Dim $Records
$Lines = _FileCountLines($io_File)
If Not _FileReadToArray($io_file, $Records) Then
ConsoleWriteError("There was an error reading > " & $io_file & @CRLF)
Exit
ElseIf _FileReadToArray($io_file, $Records) == "" Then
ConsoleWriteError("File is empty!" & @CRLF)
ElseIf Not @error Then
ConsoleWrite("> File succeeded!" & @CRLF)
EndIf
$File = FileOpen($io_file, 2)
For $ax = 1 To $Records[0]
ConsoleWrite("+> " & $Records[$ax] & @CRLF)
$Replace = StringReplace($Records[$ax], $io_word, $io_replacement)
ConsoleWrite("+> " & $Replace & @CRLF)
If _FileCountLines($io_file) < UBound($Lines) - 1 Then
FileWrite($File, $Replace & @CRLF)
Else
FileWrite($File, $Replace & @CRLF)
EndIf
Next
FileClose($File)
EndFunc
Windows Vista or 7 on Dell devices:
Replace "systemenclosure get smbiosassettag" with
"systemenclosure get serialnumber". Then it works also on Dell devices.
(thanks to Wilfred Hanekamp for sharing the script)
Download and install AutoIt for making changes to this script, and building a executable file from it. With this script, assigning a dynamic computername is possible, without using MDT integration!
ConfigMgr rocks again!
Update 15-11-2011: Because of some comments that the script isn't working I replaced the script with additional values. This time the script must be functional again.
Update 16-3-2012: Again I replaced the script with additional values. In my environment the script is running fine.
In ConfigMgr 2007 R2 there can be created Task Sequence Media. This is extremely useful when PXE boot is not available, or not allowed, and an image must be deployed. Default there will be jobs for Stand-alone media (used for offline devices), Bootable media (used for deployment) & Capture media (used for capture a reference machine). With ConfigMgr R3 there is even more functionality available in the Task Sequence Media wizard. Then there will be a job added for Prestaged Media (used for re-deployment).
In this blog the Task Sequence Bootable Media will be explained. Choose to create Bootable media, and apply it to USB or CD/DVD. Also make sure the Task Sequence used for OSD is advertised on the collection used for deployment. For a new device use "All Unknown Computers", for known devices use a deployment collection (for example). Then start the device with Bootable media. When a password is set for security reasons, this must be filled-in first.
When multiple Task Sequences are advertised on the collection, all will be displayed. Choose which OS to install, and finish the Bootable media used for OSD. The Bootable media will then copy the WinPE boot image to the local drive. After that the USB device or CD/DVD used for Bootable media must be removed.
After rebooting the Task Sequence will run the same as using PXE boot. This because the WinPE boot image and Task Sequence are stored on the local drive now. Other packages and OS image which are used in the Task Sequence will be accessed directly at the Distribution Point.
This way OSD is possible without using PXE boot functionality!
OSD = Operating System Deployment
WinPE = Windows Preinstallation Environment
In my last blog I talked about Obsolete clients in ConfigMgr. This happens during multiple deployments on the same device. There is also a known issue between ConfigMgr in combination with VMware View. Till VMware View v4.0 there was no refresh option possible, so when deleting and provisioning a new VDI desktop, a new object gets created in ConfigMgr collections.
The problem with that is you can get as many objects, for example 10 (ten) objects, which will all be online, not obsolete, and all you can use for managing the VDI desktop. When you delete an online SCCM object, all will be deleted for the same device. This is NOT an environment which can be successfully managed!
With VMware View v4.5 there is indeed a refresh option available, which can be better managed within ConfigMgr. There are additional steps needed for not getting many objects in ConfigMgr collections.
This will be explained in the following article:
View Composer supports ConfigMgr 2007 SP1 software
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1023821
Steps to take for getting rid of multiple objects are:
- Net stop ccmexec (stops SMS Agent Host service)
- Ccmdelcert.exe (can be found in ConfigMgr install folder, copy file to local disk and start it)
The ccmdelcert utility is bundled with the SMS 2007 and SMS 2003 toolkits.
- Ccmsetup.exe RESETKEYINFORMATION=TRUE (can be found in ConfigMgr Client folder, copy folder to local disk and start setup)
- Delete Smscfg.ini file in C:\Windows directory (then a unique GUID will be generated next time)
Note: When you install ConfigMgr, the application does not generate a GUID in the Windows registry. Instead, ConfigMgr stores the GUID in the file, C:\Windows\SMSCfg. You do not have to remove an ConfigMgr GUID from the Windows registry on the parent virtual machine.
- Create a new snapshot, and attach it in VMware View environment
By default, ConfigMgr generates unique GUID's in the linked-clone desktops when the ConfigMgr application agent starts up. After you perform refresh operations, the unique ConfigMgr GUID's are preserved in the linked clones.
Remember: This procedure only works with the refresh operation. Recomposing the pool will cause new GUID values to be generated.
Cool thing is you can manage VDI desktops as easy with ConfigMgr, as fysical desktops/servers. All things like OS deployment, Software distribution (also App-V packages), Patch management, Task sequences (for deploying applications), Remote Control, and so on will also work on VDI desktops! All you need is a ConfigMgr client in the VDI template, with customization for GUID's.
There is also a VMware View Optimization Guide for Windows 7 available.
http://www.vmware.com/resources/techresources/10157 and/or
http://www.vmware.com/files/pdf/VMware-View-OptimizationGuideWindows7-EN.pdf
This guide provides administrators with the information necessary to create a standard image of Windows 7 leveraging the Microsoft Deployment Toolkit or by utilizing a script-based approach to optimize a traditionally installed Windows 7 virtual machine. The recommended configuration settings optimize Windows 7 to help enhance the overall scalability and performance within a VMware View Virtual Desktop Infrastructure.
Includes files in this PDF are Commands.txt and ts.xml, which can be used for importing in MDT or a combination of ConfigMgr/MDT. These files will optimize a Windows 7 VDI template for best performance during usage!
Conclusion: ConfigMgr 2007 in combination with VMware View is the right choice for managing VDI desktops!
When deploying devices multiple times a day, for example when testing a new Task Sequence, ConfigMgr clients will become obsolete. This because everytime a device gets a new image, the ConfigMgr client will be installed again with a new GUID. The older object will be marked as obsolete, and a new object becomes available. Because of this obsolete object, OS deployment and Software distribution doesn't work anymore. This can be managed as follows.
First configure a Maintenance task for deleting them automatically. Go to Site Management > Site Settings > Site Maintenance > Tasks for enabling and configuring "Delete Obsolete Client Discovery Data". This way daily management of obsolete clients is not needed anymore. Mostly the following configuration I choose at customers:
This because this task is disabled by default, and deletes only data older the 7 (seven) days. Because I want a daily refresh in colllections, I choose to set it to 1 (one) day. This is the only thing in ConfigMgr for automatically deleting obsolete clients. But what to do when there will be multiple deployments on the same day, with the same device? Then manually delete the obsolete client is needed. For doing that, the following must be done:
Go to the All Systems collections and choose "Update collection membership". Also do a refresh afterwards. Then multiple objects can be available for the same device. Delete the Obsolete one will also then delete this object from other collections. That's pity! So remember to which collection(s) this device belongs! There is also another way for recognizing multiple objects.
Go to the collection where your device is placed for OSD (for example). Now rightclick on this collection and choose properties > Membership Rules. Click the blue computer icon for adding new devices:
Choose System Resource (Resource class) & Name (Attribute name). Fill in the device name searching for (Value):
Don't use Collection Limiting for searching devices, otherwise you have less change to find them:
When having obsolete client data, multiple devices will be seen. Choose "Select All" for adding them to the collection:
After that new devices are added, and obsolete items can be deleted:
When devices are in the right collections again, advertisements will be functional again. These are all workarounds for managing obsolete clients in ConfigMgr. When there are more possibilities for managing them , I like to hear them. Managing obsolete clients stays a challenge this way!?
Update: You can also use a query on the client name to manage collection membership instead of direct allocations. That way the new clients appear in the same collections as obsolete ones automatically. (thanks to arricc)
Most of times during a ConfigMgr 2007 implementation, there will be Delegation of Control configured. This will be done beneath Security Rights -Users/Rights in the ConfigMgr console. At that place there can be different roles configured, for example: Administrators role, Support role or Reporting role. But what to do when only Remote Control functionality is needed? In this blog I will explain what to do for configuring Remote Control in ConfigMgr.
Remote Control functionality is build-in with the ConfigMgr client. Check Site Management > Site Settings > Client Agents > Remote Tools Client Agent for configuring settings and security.
Most of time I choose this settings at General tab:
Beneath Security, Users and Groups must be added for Remote Control functionality:
This will add users and groups in the registry of all clients and servers managed within ConfigMgr 2007: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Client Components\Remote Control
In the Notification tab there are multiple choices for configuring:
Most of times I don't configure settings beneath the "Remote Assistance" and "Remote Desktop" tab. These are not needed for Remote Control functionality!
Now set security in the ConfigMgr console, by going to Security Rights -Users/Rights in the ConfigMgr console. Add a new user or group for having Remote Control rights.
I've created a RemoteControl user for this blog:
Choose to add another right or modify an existing one:
I put rights here to use Remote Tools on every collection:
Configuring is done, and the user/groups has now access rights:
For using the Remote Control functionality in ConfigMgr console now, all you hace to do is install (or virtualize) this console, and offer it to the rights users. Default the whole console will be displayed, and only the parts which you have access to, can be managed/used. You can also building a custom ConfigMgr admin console, which has for example only collections in it. See this URL for building one yourself: http://scug.be/blogs/sccm/archive/2008/07/16/building-a-custom-configmgr-2007-admin-console.aspx
Another way for giving specific users access to Remote Control functionality, is build a package with only 2 (two) files in it. This will be RC.exe and Rdpencom.dll (both can be found at ConfigMgr source > AdminUI > Bin > i386 location. Just distribute these files, and make sure security is done in the ConfigMgr console, and you're done!
The only real difference in both solutions will be the search option. In the ConfigMgr console > Collections, there can be searched in All Systems for the device which must be taken over. In the single RC.exe file solution, a name must be typed-in for having Remote Control functionality.
Remember that firewall rules must be added for having Remote Control functionality on the client when firewall is active. Otherwise an error message will follow, with a "Unable to connect" message. See this URL for used ports in ConfigMgr 2007: http://technet.microsoft.com/en-us/library/bb632618.aspx
Hope I make things clear with posting blogs like this!
In ConfigMgr 2007 R2 there can be created Task Sequence Media. This is extremely useful when PXE boot is not available, or not allowed, and an image must be created. Default there will be jobs for Stand-alone media (used for offline devices), Bootable media (used for deployment) & Capture media (used for capture a reference machine). With ConfigMgr R3 there is even more functionality available in the Task Sequence Media wizard. Then there will be a job added for Prestaged Media (used for re-deployment).
In this blog the Task Sequence Capture Media will be explained. Install a reference machine with Windows installation, Windows Updates and possibly Microsoft Office. Then start The burned Capture Media for starting ConfigMgr Task Sequence. For a Windows XP image the device must be placed in a Workgroup, and Sysprep deployment tools must be placed in C:\sysprep. On Windows Vista & 7 this is not necessary. Then only the device must be placed in a Workgroup. The Sysprep deployment tools are already build-in.
Choose Next, and fill in the path and name for storing the image, and use an account which has security rights for storing the image on that location. Choose Next again and Sysprep will start running. After the reboot WinPE will start, and a Capture job will save the image to the given location.
After capturing the only thing to do is importing the WIM image on "OSD - Operating System Images", and add it to the Distribution point. No additional Build and Capture Task Sequence is needed anymore! This becomes very handy when PXE boot is not working or not possible in a environment!
For OSD can also the "Bootable media" be used for deploying the image. This will be a different ISO file to create, and deployment will also works this way!
When installing ConfigMgr 2007 with all default roles on the local server, you must decide on which drive the Distribution point (share) will be placed.
Without any configuration the Distribution point share will be placed on the drive with the most free space. When after a while of time there is more free space on another drive, new packages will be placed on that drive. Then a new Distribution point share will be created, and software packages will be on multiple drives. This is not very handy for manage your ConfigMgr 2007 environment.
In the Software Distribution properties (Site Management - Component Configuration) there can be a default "Location of stored packages" set. Here will be the first packages stored. This is no guarantee that all packages that will added later, will be placed on the same share! To do this a workaround is available, that works also with (older) SMS 2003 environments.
Create a new txt file on all drives where you don't want a Distribution point share, and name it "no_sms_on_drive.sms". That way you make the above setting mandatory for the default "Location of stored packages". Much better that way to decide where to put the packages!
In my environment it will looks like this:
No Distribution point share (and packages) will be placed on the C:\ drive!
No Distribution point share (and packages) will be placed on the D:\ drive!
The Distribution point share (and ALL packages) will be placed on the E:\ drive! Here will be the SMSPKG folder stored, and all packages will be on the same drive. All content folders are stored on the D:\ drive this way (beneath the SCCM folder).
Hope to helped you with this (easy) solution!
With ConfigMgr advanced driver management is possible for all kind of devices. Best practice for this is creating driver packages for all different devices, and put them in the Task Sequence used for deployment. With WMI queries you can decide then which driver package will be used on different types of devices.
For more information about that see my other blog: Driver management in ConfigMgr 2007 http://henkhoogendoorn.blogspot.com/2010/10/driver-management-in-configmgr-2007.html
Now drivers are seperated in different driver packages, but what to do with the Drivers folder where all single drivers are placed? For all drivers imported there can be folders created, for dividing different drivers and hardware. Also specific Categories can be created for recognizing drivers and hardware by model. Do the following for that:
As you can see I've imported HP8000 drivers, which has been assigned to a new category. Press Next for importing this drivers in the ConfigMgr database.
All drivers are successfully imported in the ConfigMgr database. Now do it again for a new type device or model.
Now I've imported HP8100 drivers, which has also been assigned to a new category. Press Next again for importing this drivers in the ConfigMgr database.
This time (all) drivers will fail to import in the ConfigMgr database. Why is that? This because drivers can be already existing in the database. Default in ConfigMgr 2007 there can be only 1 instance per driver in the database!
But.. There is a hotfix available for solving that! (kb2213600)
http://support.microsoft.com/kb/2213600
With this hotfix drivers can be multiple times imported in different folders. So I install this hotfix in my environment, and do the same thing as before.
This time all drivers are indeed successfully imported in the ConfigMgr database. Let's have a moment now to look in the ConfigMgr console.
In the ConfigMgr console drivers are seperated now by device and hardware model. This way everyone can see to which device the drivers belongs!
When creating driver packages now, it's easy to see that the structure for driver management is the same in both Drivers and Driver packages. This way advanced driver management is created in the ConfigMgr console!
Once last thing: when deleting older drivers in the ConfigMgr console, this drivers will also be deleted from older folders from different models. To prevent this create an OLD folder, and move the old driver folders (model) beneath the OLD folder.
Also a collegue of mine (Stephan Wibier) has found that when a txt file exist in the driver source folder, this will not happen. Drivers that are the same for different models will then not deleted. This text file must exist in all folders and sub-folders then, for all drivers that are imported. This txt file has named in this example HP8000.txt for the HP8000 driver folders, and HP8100.txt for the HP8100 driver folders.
Hope you learned a lot this way about advanced driver management in ConfigMgr 2007!
Follow us on Twitter:
Henk Hoogendoorn (PQR) @henkhoogendoorn
Stephan Wibier (PQR) @stephanwibier
When installing ConfigMgr 2007, there are many default collections in the console. Most collections will be never used actually. Only the "All Systems" is handy for recognizing all devices. Best thing is to move the default collections to a new collection. How this works I will explain in this blog.
In ConfigMgr 2007 there are 17 default collections after installation. In ConfigMgr 2012 there will be default 2 User collections and 5 Device collections. Much better that way!
Because all these collections are filling up the console, it's better to moves the ones not using. To do this create a new collection (for example: All Microsoft collections). Now right-click on this collection, and choose New - Link to collection. Browse for the collection you want to move, and choose OK. This will copy the collection (and query) to the new collection.
Do this for every collection that's not used. Most of times only the "All Systems" collection is handy for use. The other collections becomes sub-collections of the new "All Microsoft collections" collection (and will be still available afterwards)! Delete the original collections after copying, these are not necessary anymore. In my console it will looks like this (after copying and deleting):
Beneath "All Microsoft collections" and "Software Distribution" are my sub-collections. The first for moved default collections, and the second for all Applications that are bound to user groups. That way the console is clear of collections that are not used often!
The moved collections can still be used for advertisements, so don't worry about that. It's only handy for a clear view in ConfigMgr 2007.
