Dell Connections License Manager 1.0 and 1.1 will create three groups in your Active Directory if the account you use to install DCLM has enough permissions in AD. If for whatever reason the install account doesn't have enough permissions to create groups in AD, you can create them manually.
These are the three groups and they must be named exactly.
1. Dell Connections License Administrators
2. Dell Connections License Operators
3. Dell Connections License Users
DCLM 1.1 contains several fixes including authentication recursion in the above groups. In DCLM 1.0, the user account had to be placed directly into the Administrators or Users group. In 1.1, you can now put a user or several users into a group, such as "SCOM Admins", and then nest that "SCOM Admins" group inside the Dell Connections License Administrators or Users groups.
This is my attempt to post things that I have encountered, found little or incomplete information for, and hope to be able to help others with. Topics will be Information Technology centric with most dealing with Microsoft System Center. The concept of a jumpbag is to contain all the things you need to survive most situations.
Tuesday, June 17, 2014
Friday, May 23, 2014
Update iDrac6 or iDrac7 firmware with ConfigMgr 2012
Update iDrac6 or iDrac7 firmware with ConfigMgr 2012
There are multiple ways to update iDrac firmware.
Recently I had a customer request that it be done specifically with
ConfigMgr 2012 because they didn't want to install any other tools at the time.
So here is how to do it silently for iDrac6 and iDrac7.
First we have to get the iDrac firmware version from all
servers by adding the class to the hardware inventory.
- Default Client Settings, Hardware Inventory, Add, Connect, servername, wmi namespace = root\cimv2\dell, check recursive. Check DELL_Firmware. Press OK all the way out to save. This will also give you the Lifecycle Controller firmware version on the servers.
- Trigger an event or wait for the Machine Policy Update to run.
- Trigger an event or wait for the Hardware Inventory Policy to run.
Next, we need to create collections based on iDrac
generation. There may be other ways to do this but I like to create a
folder and then inside each folder you can put the collections. You just
have to change the query rule next time you are ready to update all the iDracs
to whatever the latest version is at that time.
- Create one folder called iDrac6 and one called iDrac7.
- Create a collection called iDrac6 to show all machines with this iDrac under the folder for iDrac6.
- Use a Query rule to look for Dell_Firmware: Name equal to iDRAC6
- Create a collection called iDrac7 to show all machines with this iDrac under the folder for iDrac7.
- Create a collection called iDrac7 under the iDrac7 folder.
- Use a Query rule to look for Dell_Firmware: Name equal to iDRAC7
- Create a collection called iDrac6 - less than latest firmware
- Limit to iDrac6 collection
- Use a Query rule to look for Dell_Firmware: Version not equal to whatever the latest version is.
- Create a collection called iDrac7 - less than latest firmware
- Limit to iDrac7 collection
- Use a Query rule to look for Dell_Firmware: Version not equal to whatever the latest version is.
Now we create the package for each new version.
- Download the Update Package for Windows from Dell and put it in your source location.
- Create the iDrac6 firmware package.
- Select to Copy the content in the package to a package share on DPs.
- Distribute the package to the DPs.
- Create a new program in the iDrac6 package and name it after the firmware version.
- Will look similar to this “ESM_Firmware_G6N28_WN32_1.97_A00.EXE /s”. The /s on the end tells it to do a silent install.
- Run Normal or Hidden, Whether or not a user is logged on, and Suppress program notifications.
- Deploy the package and program to the iDrac6 – Less than latest collection created earlier.
- Repeat the same steps for the iDrac7 package making the necessary changes.
Thursday, May 22, 2014
Dell Connection License Manager 1.0 with Dell SCOM Management Pack 5.1
Here are some tips for getting the Server OOB licensing to work when you install the Dell SCOM MP and connect to the Dell Connections License Manager.
****Update: This issue has been resolved with DCLM 1.1. DCLM 1.1 was released 5/23/2014 and the Dell SCOM MP 5.2 was released on 5/8/2014.****
Using Dell SCOM MP 5.1 and DCLM 1.0
****Update: This issue has been resolved with DCLM 1.1. DCLM 1.1 was released 5/23/2014 and the Dell SCOM MP 5.2 was released on 5/8/2014.****
Using Dell SCOM MP 5.1 and DCLM 1.0
1. Install DCLM on the SCOM server if possible.
2. Make sure you have the correct type of license imported into DCLM. It should read "Dell Server Management Pack Suite for System Center Operations Manager. This license is for monitoring X server via out of band".
3. Use the same AD account for the Dell Device Helper COM+
object and the Operations Manager Action Account.
4. And here is the big tip. That same AD account should be put directly into the Dell
Connection License Manager Administrator group in Active Directory. You
cannot put the account in a group and nest that group in the DCLM
Adminsistrators group. It will not
work. The Action Account must be
directly in the DCLM Administrators group.
5. From the Dell Feature Management Dashboard in SCOM, make
sure you can Launch the Dell Connections License Manager (in the lower right
Task pane) and you can see the licenses in DCLM once it opens. You may need to add the URL to your Trusted Sites.
6. Refresh the Dashboard and your licenses for Out-of-Band Monitoring should show up correctly under Dell Feature Management Dashboard.
Labels:
#iwork4dell,
DCLM,
Dell Connections License Manager,
Feature Dashboard,
MP,
SCOM
Wednesday, September 7, 2011
How to move WSUS from SQL 2005 to SQL 2008 R2
I needed to move my WSUS database from SQL 2005 to a new SQL 2008 R2 server. It was difficult to find the exact directions online so I hashed together some from several places and it worked just fine. Here's how.
1. On the WSUS server, stop the "IIS Admin" service and "Update Services" service from services.msc.
2. On the SQL 2005 server, backup the SUSDB.
Right click on the running SUSDB database in SQL Management Studio and select All Tasks -> Backup.
Database = SUSDB
Backup Type = Full
Destination = Disk. I chose the desktop.
Options Page = I selected to Verify the database when finished. Press OK.
3. Copy the database over to the new SQL 2008 R2 server.
4. On the new SQL 2008 R2 server, open SQL Management Studio and connect to the database engine. Then click on New Query.
5. Type in the following and then execute by pressing the green checkmark in the toolbar:
USE MASTER
GO
ALTER DATABASE SUSDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
DROP DATABASE SUSDB
GO
6. Once that is done right click on Databases and select Restore Database.
To database = SUSDB
From database = From device and then find the file you copied over from the old SQL server.
Under Select the backup sets to restore = put a check mark next to the SUSDB database to restore.
Press OK.
7. Back on the WSUS server, open regedit.exe and navigate to HKLM\Software\Microsoft\UpdateServices\Server. Find the SqlServerName object and change that to the name of your new SQL server.
8. Restart the "IIS Admin" and "Update Services" services.
9. Open WSUS admin console and give it a moment to connect.
That's it. It worked perfectly for me and was really easy to do.
1. On the WSUS server, stop the "IIS Admin" service and "Update Services" service from services.msc.
2. On the SQL 2005 server, backup the SUSDB.
Right click on the running SUSDB database in SQL Management Studio and select All Tasks -> Backup.
Database = SUSDB
Backup Type = Full
Destination = Disk. I chose the desktop.
Options Page = I selected to Verify the database when finished. Press OK.
3. Copy the database over to the new SQL 2008 R2 server.
4. On the new SQL 2008 R2 server, open SQL Management Studio and connect to the database engine. Then click on New Query.
5. Type in the following and then execute by pressing the green checkmark in the toolbar:
USE MASTER
GO
ALTER DATABASE SUSDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
DROP DATABASE SUSDB
GO
6. Once that is done right click on Databases and select Restore Database.
To database = SUSDB
From database = From device and then find the file you copied over from the old SQL server.
Under Select the backup sets to restore = put a check mark next to the SUSDB database to restore.
Press OK.
7. Back on the WSUS server, open regedit.exe and navigate to HKLM\Software\Microsoft\UpdateServices\Server. Find the SqlServerName object and change that to the name of your new SQL server.
8. Restart the "IIS Admin" and "Update Services" services.
9. Open WSUS admin console and give it a moment to connect.
That's it. It worked perfectly for me and was really easy to do.
Thursday, April 28, 2011
SCCM client install fix
I recently had to add the SCCM client to a bunch of machines from a non-trusted domain to manage them because the group previously tasked with those machines could no longer handle it. The majority of the machines installed correctly but some did not. This fix takes a couple minutes but has fixed all of my client issues so far.
1. Check the CCMInstall\Logs\ folder. Look at the logs, in particular look at ccmexec, clientIDmanagerstartup, and locationservices logs. Also look at the ccmsetup folder for the ccmsetup.log and client.msi.log. These logs can help you pinpoint the reasons for the installation problems.
2. If you see errors like "Unable to retrieve AMP for site code" in the CCMInstall\logs\LocationServices.log, the install may see more than 1 client certificate and not be able to pick one. If you AD automatically enrolls the machines and issues a new cert, you can run mmc, add the certificates snap-in for the computer account, and remove the client certificates under personal. If you can't delete those add CCMFIRSTCERT=1 to the client install options. There are some other things you can do also to make sure the correct certificates are available on the untrusted client.
3. Uninstall the SCCM client if it already exists but isn't working correctly. Go to a cmd window and change to the ccmsetup folder. run ccmsetup.exe /uninstall.
4. (optional and I haven't seen any effects from not using it) CCMClean does still work in SCCM 2007. You can download the SMS2003ToolKit and copy just that one tool. It helps remove registry links and orphaned files if any.
5. Cmd window and run "net stop winmgmt". You may have to run this twice to get it to stop because sometimes the service will start again immediately. As soon as it stops rename the c:\windows\system32\wbem\repository folder to oldrepository. This will reset WMI when the service restarts which we will do with a reboot in a minute.
6. Delete the c:\windows\system32\ccm and ccmsetup folders on 32bit machines or the c:\windows\syswow64\ccm folder on 64bit machines.
7. Restart the machine and you will have a repaired WMI and ready for a clean install of the SCCM client.
1. Check the CCMInstall\Logs\ folder. Look at the logs, in particular look at ccmexec, clientIDmanagerstartup, and locationservices logs. Also look at the ccmsetup folder for the ccmsetup.log and client.msi.log. These logs can help you pinpoint the reasons for the installation problems.
2. If you see errors like "Unable to retrieve AMP for site code" in the CCMInstall\logs\LocationServices.log, the install may see more than 1 client certificate and not be able to pick one. If you AD automatically enrolls the machines and issues a new cert, you can run mmc, add the certificates snap-in for the computer account, and remove the client certificates under personal. If you can't delete those add CCMFIRSTCERT=1 to the client install options. There are some other things you can do also to make sure the correct certificates are available on the untrusted client.
3. Uninstall the SCCM client if it already exists but isn't working correctly. Go to a cmd window and change to the ccmsetup folder. run ccmsetup.exe /uninstall.
4. (optional and I haven't seen any effects from not using it) CCMClean does still work in SCCM 2007. You can download the SMS2003ToolKit and copy just that one tool. It helps remove registry links and orphaned files if any.
5. Cmd window and run "net stop winmgmt". You may have to run this twice to get it to stop because sometimes the service will start again immediately. As soon as it stops rename the c:\windows\system32\wbem\repository folder to oldrepository. This will reset WMI when the service restarts which we will do with a reboot in a minute.
6. Delete the c:\windows\system32\ccm and ccmsetup folders on 32bit machines or the c:\windows\syswow64\ccm folder on 64bit machines.
7. Restart the machine and you will have a repaired WMI and ready for a clean install of the SCCM client.
Friday, April 15, 2011
Change in how to apply Patch with SCCM Client push
There used to be a couple of articles online explaining how to add the PATCH=... command to the Client Push installation properties, but those articles have disappeared. I also began seeing error 1635 on machines trying to install with that argument.
The new way to add a patch, such as http://support.microsoft.com/kb/977384, is this:
In the Client source folder (%installdir%\Microsoft Configuration Manager\Client) create a folder called ClientPatch. Copy the .msp file into that folder.
So it looks like this:
E:\
Microsoft Configuration Manager\
Client\
ClientPatch\
sccm2007ac-sp2-kb977384-x86-enu.msp
That's it. SCCM will automatically try to install any .msp files you put in that folder when the Client is pushed to machines. Once I changed to that and removed the PATCH argument, my client pushes started working again.
The new way to add a patch, such as http://support.microsoft.com/kb/977384, is this:
In the Client source folder (%installdir%\Microsoft Configuration Manager\Client) create a folder called ClientPatch. Copy the .msp file into that folder.
So it looks like this:
E:\
Microsoft Configuration Manager\
Client\
ClientPatch\
sccm2007ac-sp2-kb977384-x86-enu.msp
That's it. SCCM will automatically try to install any .msp files you put in that folder when the Client is pushed to machines. Once I changed to that and removed the PATCH argument, my client pushes started working again.
Wednesday, April 6, 2011
Windows Malicious Software Removal Tool and SCCM Software Updates
The MSRT was not designed to be pushed as a regular update through SCCM Software Updates. If you put it in an SU deployment package your machines will fail to install and will notify the users repeatedly that it failed. If you want to push this update each month, you can do so with Group Policy or as a Software Package in SCCM. Here is the related Technet article.
http://support.microsoft.com/?kbid=891716
http://support.microsoft.com/?kbid=891716
Subscribe to:
Comments (Atom)