Showing posts with label SMS SITE SQL BACKUP. Show all posts
Showing posts with label SMS SITE SQL BACKUP. Show all posts

9/27/2010

NULL Values in SCCM Hardware Inventory

I tried to capture the value of the registry key HKLM\SOFTWARE\YOURCOMPANY\Department from all systems independed of the OS architecture. I had the problem that the inventory delivered NULL Values in the database, although everything seemed to be configured correctly. The problem occurred very sporadic. Sometimes a system delivered a value and sometimes it didn’t.
Here’s my basic configuration.mof and sms_def.mof

configuration.mof
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("CustomHINV86", NOFAIL)
[DYNPROPS]
class CustomHINV86
{
[key] string KeyName = "";
string Department;
};

[DYNPROPS]
instance of CustomHINV86
{
KeyName="CustomHINV";
[PropertyContext("localHKEY_LOCAL_MACHINE\\SOFTWARE\\YOURCOMPANYDepartment"),
Dynamic, Provider("RegPropProv")]
Department;
};

#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("CustomHINV64", NOFAIL)
[DYNPROPS]
class CustomHINV64
{
[key] string KeyName = "";
string Department;
};

[DYNPROPS]
instance of CustomHINV64
{
KeyName="CustomHINV";
[PropertyContext("localHKEY_LOCAL_MACHINE\\SOFTWARE\\YOURCOMPANYDepartment"),
Dynamic, Provider("RegPropProv")]
Department;
};



sms_def.mof
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("CustomHINV86", NOFAIL)
[SMS_Report(TRUE),
SMS_Group_Name("Your Custom HINV"),
SMS_Class_ID("YOURCOMPANYYour Custom HINV1.0"),
SMS_Context_1 ("__ProviderArchitecture=32uint32"),
SMS_Context_2 ("__RequiredArchitecture=trueboolean")]

Class CustomHINV86: SMS_Class_Template
{
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] String Department;
};

#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("CustomHINV64", NOFAIL)
[SMS_Report(TRUE),
SMS_Group_Name("Your Custom HINV"),
SMS_Class_ID("YOURCOMPANYYour Custom HINV1.0"),
SMS_Context_1 ("__ProviderArchitecture=64uint32"),
SMS_Context_2 ("__RequiredArchitecture=trueboolean")]

Class CustomHINV64: SMS_Class_Template
{
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] String Department;
};


The result was the following entry in the SQL table
ResourceIDGroupIDRevisionIDAgentIDTimeStampDepartment0KeyName0
3313114.09.2010 16:59:19NULLCustomHINV


That’s the problem!
As the hardware inventory listed above is designed for both OS architecture, there should be created two entries in the table. I then compared those entries with some working one, from another customization and saw the differences.
The entries were overwritten, as the column KeyName0 is not unique. This also explained the sporadic behavior. Depending on which inventory entry (32bit or 64 bit) was written into the database in which order, the first one was overwritten.
The correct entries for a 64 bit system should look like this:
ResourceIDGroupIDRevisionIDAgentIDTimeStampDepartment0KeyName0
3313114.09.2010 16:59:19NULLCustomHINV86
3313114.09.2010 16:59:19MyValueCustomHINV64


So the result was to customize the configuration.mof file the get unique KeyName0 columns. Here it is:
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("CustomHINV86", NOFAIL)
[DYNPROPS]
class CustomHINV86
{
[key] string KeyName = "";
string Department;
};

[DYNPROPS]
instance of CustomHINV86
{
KeyName="CustomHINV86";
[PropertyContext("localHKEY_LOCAL_MACHINE\\SOFTWARE\\YOURCOMPANYDepartment"),
Dynamic, Provider("RegPropProv")]
Department;
};


#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("CustomHINV64", NOFAIL)
[DYNPROPS]
class CustomHINV64
{
[key] string KeyName = "";
string Department;
};

[DYNPROPS]
instance of CustomHINV64
{
KeyName="CustomHINV64";
[PropertyContext("localHKEY_LOCAL_MACHINE\\SOFTWARE\\YOURCOMPANYDepartment"),
Dynamic, Provider("RegPropProv")]
Department;
};

10/01/2009

ConfigMgr SQL Backup Service on the wrong volume - Workaround

Your going to install a ConfigMgr 2007 with the database stored on a remote SQL Cluster server. During the installation of the database there will be installed a ConfigMgr database backup service on both cluster nodes. This service is named SMS SITE SQL BACKUP. By default during this installation the volume with most free space is used to store the service. This can cause various problems on a cluster. E.g. Systemstate backup fails, as a service running on a shared volume cannot be accessed.
To bypass this behavior there should be created a file named NO_SMS_ON_DRIVE.SMS on the root of each volume of the cluster which shell not be the volume for the service installation.
If the service installation is already done on a shared volume, it's getting difficult.
There are various opinions how this problem could be solved...
For example one is to move the Configmgr database to another server, create the file on the volume and move it back to the server, so that the installation is running once more and the volumes with the file will be skipped. Another option which is discussed is to do a site repair.
Then i've found the following post from Razmus on Microsoft forums. Then i did the following:

Note: X=Wrong drive letter, Servername=Your MgmtPoint

1. I moved the service folder X:\SMS_Servername from the wrong volume to the desired one.
2. In the Management Points registry go to the path HKLM\SOFTWARE\Microsoft\SMS\Components\SMS_SITE_COMPONENT_MANAGER\Multisite Component Servers. Below this key there are listed two subkeys named as both cluster nodes. On each of this key there is a value named Installation Directory. Here should be the driveletter also changed.
3. In the registry of each cluster node go to the path HKLM\SYSTEM\CurrentControlSet\Services\SMS_SITE_SQL_BACKUP_Servername and change the value ImagePath to the new driveletter also
After restarting the service SMS_SITE_SQL_BACKUP_Servername on the cluster node the new execution path should be changed to the new volume. Afterwards i removed the service folder from the wrong volume to make sure that the service is really running on the selected volume. This seems to work. The only problem is still have is, that the folder is still created on the wrong volume when the service is restarted. But it only contains the logfile. I can live with this behaviour, as the executable is running on the correct one.