Wow, long time since last post..
I've got some more bits and pieces to put up as results of recently integrating our App-V Full Infrastructure model into Config Manager 2007.
I had a lot of drama with one high profile user whose app-v applications were not republishing after the integration was taking place.
The Config Manager VirtualApp log was showing success:
Executing command line: "C:\Program Files\Microsoft Application Virtualization Client\SFTMIME.COM" PUBLISH PACKAGE:"{EBFB37EC-50F8-4AA1-B252-B665C057E2B0}" /GLOBAL /MANIFEST "C:\\WINDOWS\\system32\\CCM\\Cache\\INT00289.1.S-1-5-21-1093918724-1084531541-3253023803-7346\\SapGui20.V01_manifest.xml"
The command completed with exit code 0.
Successfully published the shortcuts and file type associations for package SapGui20.V01.
So, all good i thought. But the application was not loaded into WMI, no shortcuts were visible etc.
Next step was to take a look at the App-V log (sftlog.txt). I noticed errors in this log :
Could not load OSD file: \\servername\content\blahblah.osd
This server is part of the old App-V full infrastructure! Which is obviously why the app wasn't actually being published successfully. I had a look at that machines registry, compared it to some functional machines and saw that the OSDSourceRoot App-V key had been set to \\servername\content.
Once I cleared this and reran the advertisement, it was all happening.
So what I take from this is that the OSDSourceRoot actually overrides the OverrideURL, which i didn't expect at all. If you have this set via policy, you may be in for some pain when you go to integrate App-V into Config Manager.
Hope that helps someone!
Wednesday, September 29, 2010
Thursday, July 8, 2010
App-V Visio 2010 Licensing Errors
We have recently deployed Visio 2010 via App-V to generally good results. However every few days I would receive notification from the service desk of a user who had a licensing error when launching Visio 2010 :
![]()
The help desk were fixing this by repairing the Microsoft Office 2010 Deployment Kit for App-V.
Seemed a bit strange to me, so I investigated the one or two of the troublesome machines and found that the Office Software Protection Platform service had stopped.
Further to that, I saw that the service was set to Manual start, with no recovery options.
This basically means that once this service fails, its failed for good.
I checked out a few more machines that had Visio deployed, and yup, all of them had the OSPP service set to manual start. It seems the Office 2010 Deployment kit installer creates this serrvice with a manual start type.
To resolve, I needed to create a transform for the OffVirt.MSI file.
I used Microsoft's tool, Orca to do this.
First step: Open the MSI with Orca.
Right click the MSI, and select 'Edit with Orca'. Orca will open, and you will see all the MSI tables.
Then select transform > new transform
This will give you the screen displayed below:
From there, go to the ServiceInstall table, and change the StartType value from 3 (Manual) to 2 (automatic)
Click Transform > Generate Transform and enter a name for your transform, and save it.
Alright, transform created! Now just run the MSI with the transform as follows:
msiexec /i offvirt.msi TRANSFORMS="yourtransformname.mst"
With any other options you need in there.
And with that you have an install that will set the Protection service to 'Automatic'. Phew.
The help desk were fixing this by repairing the Microsoft Office 2010 Deployment Kit for App-V.
Seemed a bit strange to me, so I investigated the one or two of the troublesome machines and found that the Office Software Protection Platform service had stopped.
Further to that, I saw that the service was set to Manual start, with no recovery options.
This basically means that once this service fails, its failed for good.
I checked out a few more machines that had Visio deployed, and yup, all of them had the OSPP service set to manual start. It seems the Office 2010 Deployment kit installer creates this serrvice with a manual start type.
To resolve, I needed to create a transform for the OffVirt.MSI file.
I used Microsoft's tool, Orca to do this.
First step: Open the MSI with Orca.
Right click the MSI, and select 'Edit with Orca'. Orca will open, and you will see all the MSI tables.
Then select transform > new transform
This will give you the screen displayed below:
From there, go to the ServiceInstall table, and change the StartType value from 3 (Manual) to 2 (automatic)
Click Transform > Generate Transform and enter a name for your transform, and save it.
Alright, transform created! Now just run the MSI with the transform as follows:
msiexec /i offvirt.msi TRANSFORMS="yourtransformname.mst"
With any other options you need in there.
And with that you have an install that will set the Protection service to 'Automatic'. Phew.
Monday, June 21, 2010
Windows Deployment Service not starting
One of our ConfigMgr PXE Service points was not functioning as it should, was not servicing any clients.
When I went to restart the WDS Service, I received the following error:
Very odd. I enabled Tracing on the WDS Service (by switching the EnableFileTracing key located here - HKLM\Software\Microsoft\Tracing\WDSSERVER - from a 0 to a 1) and reviewed the log generated when I tried to restart the service again.
I was receiving errors such as :
[5108] 10:30:04: [d:\rtm\base\ntsetup\opktools\wds\wdssrv\server\src\wdsprovhdl.cpp:169] Expression: , Win32 Error=3238332162
[5108] 10:30:05: [1762][WDSPXE] [d:\rtm\base\ntsetup\opktools\wds\wdssrv\wdspxe\src\pxeprov.cpp:172] Expression: , Win32 Error=2
[5108] 10:30:05: [1762][WDSPXE] [SMSPXE] Initialization failed (rc=2)
[5108] 10:30:05: [1762][WDSPXE] [d:\rtm\base\ntsetup\opktools\wds\wdssrv\wdspxe\src\pxeprovhdl.cpp:481] Expression: , Win32 Error=2
[5108] 10:30:05: [1762][WDSPXE] -> CBannedGuids::Shutdown
[5108] 10:30:05: [1762][WDSPXE] <- CBannedGuids::Shutdown=0
[5108] 10:30:05: [1762][WDSPXE] [d:\rtm\base\ntsetup\opktools\wds\wdssrv\wdspxe\src\pxeprovhdl.cpp:598] Expression: , Win32 Error=2
[5108] 10:30:05: [1762][WDSPXE] [d:\rtm\base\ntsetup\opktools\wds\wdssrv\wdspxe\src\pxemain.cpp:201] Expression: , Win32 Error=2
[5108] 10:30:05: [d:\rtm\base\ntsetup\opktools\wds\wdssrv\server\src\wdsprovider.cpp:147] Expression: , Win32 Error=2
[5108] 10:30:05: [WDSPXE] Initialization Failed (rc=2)
Error code 2 is a file not found error. Something had gone seriously amiss with the SMSPXE provider.
This had to be up and running ASAP, so I did not have time to remove the packages off the PXE point, remove the PXE role, Re-add the role, and redistribute the images.
To resolve, I ran PXE.MSI on the affected server (this is located [SMSINSTALLDIR]\Bin\PXE.MSI).
This repaired the PXE setup on that machine, re-registered providers etc. The service would then start, and the server is now servicing pxe clients.
When I went to restart the WDS Service, I received the following error:
Very odd. I enabled Tracing on the WDS Service (by switching the EnableFileTracing key located here - HKLM\Software\Microsoft\Tracing\WDSSERVER - from a 0 to a 1) and reviewed the log generated when I tried to restart the service again.
I was receiving errors such as :
[5108] 10:30:04: [d:\rtm\base\ntsetup\opktools\wds\wdssrv\server\src\wdsprovhdl.cpp:169] Expression: , Win32 Error=3238332162
[5108] 10:30:05: [1762][WDSPXE] [d:\rtm\base\ntsetup\opktools\wds\wdssrv\wdspxe\src\pxeprov.cpp:172] Expression: , Win32 Error=2
[5108] 10:30:05: [1762][WDSPXE] [SMSPXE] Initialization failed (rc=2)
[5108] 10:30:05: [1762][WDSPXE] [d:\rtm\base\ntsetup\opktools\wds\wdssrv\wdspxe\src\pxeprovhdl.cpp:481] Expression: , Win32 Error=2
[5108] 10:30:05: [1762][WDSPXE] -> CBannedGuids::Shutdown
[5108] 10:30:05: [1762][WDSPXE] <- CBannedGuids::Shutdown=0
[5108] 10:30:05: [1762][WDSPXE] [d:\rtm\base\ntsetup\opktools\wds\wdssrv\wdspxe\src\pxeprovhdl.cpp:598] Expression: , Win32 Error=2
[5108] 10:30:05: [1762][WDSPXE] [d:\rtm\base\ntsetup\opktools\wds\wdssrv\wdspxe\src\pxemain.cpp:201] Expression: , Win32 Error=2
[5108] 10:30:05: [d:\rtm\base\ntsetup\opktools\wds\wdssrv\server\src\wdsprovider.cpp:147] Expression: , Win32 Error=2
[5108] 10:30:05: [WDSPXE] Initialization Failed (rc=2)
Error code 2 is a file not found error. Something had gone seriously amiss with the SMSPXE provider.
This had to be up and running ASAP, so I did not have time to remove the packages off the PXE point, remove the PXE role, Re-add the role, and redistribute the images.
To resolve, I ran PXE.MSI on the affected server (this is located [SMSINSTALLDIR]\Bin\PXE.MSI).
This repaired the PXE setup on that machine, re-registered providers etc. The service would then start, and the server is now servicing pxe clients.
Tuesday, June 8, 2010
ConfigManager Task Sequence not continuing - Clients in Provisioning Mode
Recently we had a problem where a lot of clients were not completing their OSD Task Sequence, instead showing up in reporting as still running.
These clients were unable to be managed, and would often be in Provisioning Mode.
Turns out this was due to one of the steps in the task sequence requiring a reboot. The software (in this case it was Cisco VPN Client) would install, and then reboot after about 2-3 minutes of installing. This reboot was not handled by the TS and was unhandled. This would cause the client to stop running the TS, boot into windows and leave the client in provisioning mode.
To resolve: suppresed the reboot in the software installation package, and clients would then finish running TS.
The easiest way to find the trouble software is look for the step before the stuck running step. In my case, client would stay running step 79. Step 78 was the troublesome package.
Hope this helps anyone, took me a long time to figure out.
These clients were unable to be managed, and would often be in Provisioning Mode.
Turns out this was due to one of the steps in the task sequence requiring a reboot. The software (in this case it was Cisco VPN Client) would install, and then reboot after about 2-3 minutes of installing. This reboot was not handled by the TS and was unhandled. This would cause the client to stop running the TS, boot into windows and leave the client in provisioning mode.
To resolve: suppresed the reboot in the software installation package, and clients would then finish running TS.
The easiest way to find the trouble software is look for the step before the stuck running step. In my case, client would stay running step 79. Step 78 was the troublesome package.
Hope this helps anyone, took me a long time to figure out.
Thursday, May 27, 2010
SMS_MP_CONTROL_MANAGER Warnings 5416 & 5418
After extending the sms_def.mof and configuration.mof I noticed a large amount of 5416 and 5418 warnings in the SMS_MP_CONTROL_MANAGER with the text:
"MP could not find some class or property definitions when processing Hinv as they are apparently missing in sms_def.mof. Unknown classes and properties have been ignored and a MIF file generated with all the classes and properties that could be found.
Possible cause: This might indicate that the report has become obsolete due to a new HW inventory policy or that a customer's private definitions haven't been properly propagated to the sms_def.mof at the PSS.
Solution: See if the missing classes or properties are genuinely missing in the current sms_def.mof and find out why the client put them in the xml report."
Uh-oh!
So, I had to find out what was going on here, obviously something related to the changes made.
I had a look at DATALDR.LOG on the primary site, no errors there to speak of.
Checked out MP_HINV.LOG and found quite a few warnings..
"Hinv: property name not found in the mapping table: KeyName"
So looks like theres a problem with KeyName.
Comparing the sms_def to the configuration mof files I saw the problem:
sms_def.mof
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("ProvisioningMode", NOFAIL)
[SMS_Report(TRUE),SMS_Group_Name("ProvisioningMode"),SMS_Class_ID("HEALTH|ProvisioningMode|1.0")]
Class ProvisioningMode: SMS_Class_Template
{
[SMS_Report(TRUE)] String ProvisioningMode;
};
configuration.mof
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("ProvisioningMode", NOFAIL)
[DYNPROPS]
Class ProvisioningMode
{
[key] string KeyName;
String ProvisioningMode;
};
[DYNPROPS]
Instance of ProvisioningMode
{
keyname="SystemCenter.fr";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\CCM\\CcmExec|ProvisioningMode"),Dynamic,Provider("RegPropProv")] ProvisioningMode;
};
See the problem? I had forgotten to add KeyName to the sms_def.mof, meaning it couldnt map this, in turn causing my warnings.
Added the missing line to sms_def ([SMS_Report(TRUE),key] string KeyName;) and the problem has now been resolved. No more warnings, and MP_HINV is processing inventory data very happily.
Sweet deal!
"MP could not find some class or property definitions when processing Hinv as they are apparently missing in sms_def.mof. Unknown classes and properties have been ignored and a MIF file generated with all the classes and properties that could be found.
Possible cause: This might indicate that the report has become obsolete due to a new HW inventory policy or that a customer's private definitions haven't been properly propagated to the sms_def.mof at the PSS.
Solution: See if the missing classes or properties are genuinely missing in the current sms_def.mof and find out why the client put them in the xml report."
Uh-oh!
So, I had to find out what was going on here, obviously something related to the changes made.
I had a look at DATALDR.LOG on the primary site, no errors there to speak of.
Checked out MP_HINV.LOG and found quite a few warnings..
"Hinv: property name not found in the mapping table: KeyName"
So looks like theres a problem with KeyName.
Comparing the sms_def to the configuration mof files I saw the problem:
sms_def.mof
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("ProvisioningMode", NOFAIL)
[SMS_Report(TRUE),SMS_Group_Name("ProvisioningMode"),SMS_Class_ID("HEALTH|ProvisioningMode|1.0")]
Class ProvisioningMode: SMS_Class_Template
{
[SMS_Report(TRUE)] String ProvisioningMode;
};
configuration.mof
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("ProvisioningMode", NOFAIL)
[DYNPROPS]
Class ProvisioningMode
{
[key] string KeyName;
String ProvisioningMode;
};
[DYNPROPS]
Instance of ProvisioningMode
{
keyname="SystemCenter.fr";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\CCM\\CcmExec|ProvisioningMode"),Dynamic,Provider("RegPropProv")] ProvisioningMode;
};
See the problem? I had forgotten to add KeyName to the sms_def.mof, meaning it couldnt map this, in turn causing my warnings.
Added the missing line to sms_def ([SMS_Report(TRUE),key] string KeyName;) and the problem has now been resolved. No more warnings, and MP_HINV is processing inventory data very happily.
Sweet deal!
Tuesday, May 25, 2010
Config Manager and AppV Full Infrastructure Model - Config Manager Reporting
I have an App V setup that is a little unorthodox..(AppV in the Full infrastructure model alongside Configuration Manager). This was done to take advantage of the active upgrade and dedicated reporting/licensing features of the AppV Management Server.
We have multiple sites across two countries, but do not have AD Sites for each of these locations. This makes managing AppV a bit tricky, as we need clients in each site to go to their nearest streaming server (streaming server role has been installed on each Config Manager DP).
I have done this by a similar mechanism as Config Manager's Boundaries. A GPO was created, and a Group Policy Preference Registry collection was created for each site, specifying the Application Source Root and Icon Source Root to be the Streaming Server for that site. This was filtered to only the subnets in that site.
So this looks kinda like this:
Registry Collection
Site1 (targeted to subnet 192.168.1.x)
Application Source Root : Server1
Site2 (targeted to subnet 192.168.2.x)
Application Source Root : Server2
Etc etc.
While this may look cumbersome, it actually works very well and enables easy roaming of clients between sites if they need to.
The problem I had was actually having some way of checking the Application Source Root location.
This was quickly resolved by adding to Config Managers inventory to inventory reg keys.
This was done by adding the following to the SMS_DEF.MOF file:
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("AppVLocation", NOFAIL)
[SMS_Report(TRUE),SMS_Group_Name("AppVLocation"),SMS_Class_ID("CUSTOM|AppVLocation|1.0")]
Class AppVLocation: SMS_Class_Template
{
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] String ApplicationSourceRoot;
[SMS_Report(TRUE)] String IconSourceRoot;
};
And this to the Configuration.mof file:
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("AppVLocation", NOFAIL)
[DYNPROPS]
Class AppVLocation
{
[key] string KeyName;
String ApplicationSourceRoot;
String IconSourceRoot;
};
[DYNPROPS]
Instance of AppVLocation
{
keyname="SystemCenter.fr";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\SoftGrid\\4.5\\Client\\Configuration|ApplicationSourceRoot"),Dynamic,Provider("RegPropProv")] ApplicationSourceRoot;
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\SoftGrid\\4.5\\Client\\Configuration|IconSourceRoot"),Dynamic,Provider("RegPropProv")] IconSourceRoot;
};
Hey presto, reg keys being collected.
Once I had kicked off inventory and one machine, and confirmed that the new table (dbo.AppVLocation_DATA) had been created, it was time to write a report to make use of these values:
select v_R_System.Netbios_Name0 , v_GS_AppVLocation0.ApplicationSourceRoot0 AS 'Application Source' from v_R_System inner join v_GS_AppVLocation0 on v_GS_AppVlocation0.ResourceID = v_R_System.ResourceID where v_R_System.Operating_System_Name_and0 LIKE 'Microsoft Windows NT Workstation%'
This gives me a nice, basic report telling me which machines are assigned to which streaming server, and also more importantly, any machines that do not have an Application Source Root set for any reason.
Choice!
We have multiple sites across two countries, but do not have AD Sites for each of these locations. This makes managing AppV a bit tricky, as we need clients in each site to go to their nearest streaming server (streaming server role has been installed on each Config Manager DP).
I have done this by a similar mechanism as Config Manager's Boundaries. A GPO was created, and a Group Policy Preference Registry collection was created for each site, specifying the Application Source Root and Icon Source Root to be the Streaming Server for that site. This was filtered to only the subnets in that site.
So this looks kinda like this:
Registry Collection
Site1 (targeted to subnet 192.168.1.x)
Application Source Root : Server1
Site2 (targeted to subnet 192.168.2.x)
Application Source Root : Server2
Etc etc.
While this may look cumbersome, it actually works very well and enables easy roaming of clients between sites if they need to.
The problem I had was actually having some way of checking the Application Source Root location.
This was quickly resolved by adding to Config Managers inventory to inventory reg keys.
This was done by adding the following to the SMS_DEF.MOF file:
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("AppVLocation", NOFAIL)
[SMS_Report(TRUE),SMS_Group_Name("AppVLocation"),SMS_Class_ID("CUSTOM|AppVLocation|1.0")]
Class AppVLocation: SMS_Class_Template
{
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] String ApplicationSourceRoot;
[SMS_Report(TRUE)] String IconSourceRoot;
};
And this to the Configuration.mof file:
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("AppVLocation", NOFAIL)
[DYNPROPS]
Class AppVLocation
{
[key] string KeyName;
String ApplicationSourceRoot;
String IconSourceRoot;
};
[DYNPROPS]
Instance of AppVLocation
{
keyname="SystemCenter.fr";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\SoftGrid\\4.5\\Client\\Configuration|ApplicationSourceRoot"),Dynamic,Provider("RegPropProv")] ApplicationSourceRoot;
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\SoftGrid\\4.5\\Client\\Configuration|IconSourceRoot"),Dynamic,Provider("RegPropProv")] IconSourceRoot;
};
Hey presto, reg keys being collected.
Once I had kicked off inventory and one machine, and confirmed that the new table (dbo.AppVLocation_DATA) had been created, it was time to write a report to make use of these values:
select v_R_System.Netbios_Name0 , v_GS_AppVLocation0.ApplicationSourceRoot0 AS 'Application Source' from v_R_System inner join v_GS_AppVLocation0 on v_GS_AppVlocation0.ResourceID = v_R_System.ResourceID where v_R_System.Operating_System_Name_and0 LIKE 'Microsoft Windows NT Workstation%'
This gives me a nice, basic report telling me which machines are assigned to which streaming server, and also more importantly, any machines that do not have an Application Source Root set for any reason.
Choice!
Sunday, May 16, 2010
Unable to edit Task Sequences - SCCM
Today it was discovered that any task sequences I tried to edit and save the changes to, were failing with a "Unable to Store Task Sequence" error. Neat.
Had a look in the TaskSequenceProvider log, and found the following :
[PID: 29436] Invoking method SMS_TaskSequence.SaveToXml TaskSequenceProvider 5/17/2010 11:19:07 AM 21712 (0x54D0)
Failed verifying schema version property in wmi sequence 0x80004005 (2147500037) TaskSequenceProvider 5/17/2010 11:19:07 AM 21712 (0x54D0)
Failed to store the WMI task sequence as XML 0x80004005 (2147500037) TaskSequenceProvider 5/17/2010 11:19:07 AM 21712 (0x54D0)
Seems WMI went belly up on the Primary Site Server.. A restart of the
Windows Management Instrumentation service fixed this right up, and task sequences are working once more. A real good start to the day..
Had a look in the TaskSequenceProvider log, and found the following :
[PID: 29436] Invoking method SMS_TaskSequence.SaveToXml TaskSequenceProvider 5/17/2010 11:19:07 AM 21712 (0x54D0)
Failed verifying schema version property in wmi sequence 0x80004005 (2147500037) TaskSequenceProvider 5/17/2010 11:19:07 AM 21712 (0x54D0)
Failed to store the WMI task sequence as XML 0x80004005 (2147500037) TaskSequenceProvider 5/17/2010 11:19:07 AM 21712 (0x54D0)
Seems WMI went belly up on the Primary Site Server.. A restart of the
Windows Management Instrumentation service fixed this right up, and task sequences are working once more. A real good start to the day..
Thursday, May 13, 2010
State Migration Point failing to start
One of the many State Migration Points I have failed the install (due to the above certificate error). Also, as part of the initial role assignment, the wrong drive was specified.
The site role was removed, web cert added as per above, then readded with the correct path. As a result, the role installed successfully. However, I was then receiving messages about the State Migration Point starting, then stopping unexpectedly.
Checking the SMPMGR.LOG file, I found the following lines :
Creating directory "D:\USMT\SMPSTORED_378B856C$" SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)
Cannot create D:\USMT, Win32 Error = 3 SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)
ERROR: Failed to create directory "D:\USMT\SMPSTORED_378B856C$" SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)
HandleSMPRegistryChanges failed. error (0x80004005). SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)
SMPManager failed to start, Error = (0x80004005). SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)
So the SMP was trying to create the folder on the old path, the one specified before I removed and readded the role with the correct part. Damn!
I took a look at the reg key that has the SMP settings (HKLM\Software\Microsoft\SMS\SMP\StateStore) and found TWO subkeys, one for the incorrect path (D:\USMT) and one with the correct path (E:\USMT).
Seems it only reads the first key in here (which makes sense).. Remove the incorrect subkey, and start the SMS_STATE_MIGRATION_POINT component via the service manager.
Check the SMPMGR.LOG file, and bingo! path is created, and component is now ticking along nicely.
The site role was removed, web cert added as per above, then readded with the correct path. As a result, the role installed successfully. However, I was then receiving messages about the State Migration Point starting, then stopping unexpectedly.
Checking the SMPMGR.LOG file, I found the following lines :
Creating directory "D:\USMT\SMPSTORED_378B856C$" SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)
Cannot create D:\USMT, Win32 Error = 3 SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)
ERROR: Failed to create directory "D:\USMT\SMPSTORED_378B856C$" SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)
HandleSMPRegistryChanges failed. error (0x80004005). SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)
SMPManager failed to start, Error = (0x80004005). SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)
So the SMP was trying to create the folder on the old path, the one specified before I removed and readded the role with the correct part. Damn!
I took a look at the reg key that has the SMP settings (HKLM\Software\Microsoft\SMS\SMP\StateStore) and found TWO subkeys, one for the incorrect path (D:\USMT) and one with the correct path (E:\USMT).
Seems it only reads the first key in here (which makes sense).. Remove the incorrect subkey, and start the SMS_STATE_MIGRATION_POINT component via the service manager.
Check the SMPMGR.LOG file, and bingo! path is created, and component is now ticking along nicely.
Wednesday, May 12, 2010
Configuration Manager - State Migration Point Install Failure
Just had an issue with the install of a SMP to one of our servers.
I received the below errors in the SMPMSI.LOG :
The state of web site "Default Web Site" is Started.
ERROR: Certificate is not configured on the website for SSL.
ERROR: Validate IIS failed with 0x80004005.
@@ERR:25055
Product: SMS State Migration point -- Internal Error 25055. 80004005
I took a quick look on the server, and lo and behold there was no server cert in IIS under secure communication.
Quick fix (for a change!) - Requested a web server cert, and attached it.
I then removed the State Migration Point role, and readded it.
SMP is now happy, sweet deal!
I received the below errors in the SMPMSI.LOG :
The state of web site "Default Web Site" is Started.
ERROR: Certificate is not configured on the website for SSL.
ERROR: Validate IIS failed with 0x80004005.
@@ERR:25055
Product: SMS State Migration point -- Internal Error 25055. 80004005
I took a quick look on the server, and lo and behold there was no server cert in IIS under secure communication.
Quick fix (for a change!) - Requested a web server cert, and attached it.
I then removed the State Migration Point role, and readded it.
SMP is now happy, sweet deal!
Tuesday, May 11, 2010
Inventory Data Loader warnings + more..
This blog is kind of a reference for myself, but if anyone else makes use of the random pieces I put here, then all the better, all about sharing information.
I don't know about anyone else, but now and then I receive warnings in my Inventory Data Loader component. These are normally in the format :
"SMS Inventory Data Loader failed to process the delta MIF file "BLAH" and has moved it to "D:\Program Files\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\ucq33ee1.MIF."
These only appear to happen for some delta inventory info, and subsequent resynchs will produce the same message.
A full Inventory Resynchronization fixes these clients right up.
The Operations Management team wanted a way they could easily identify which clients were causing these warnings, and a way for our help desk to resolve them.
To do this, I took a two pronged approach.
1) Created a script that parses the computername from the BADMIF files and adds it to a spreadsheet. (you can download this here if you want, all normal disclaimers apply, im not responsible for anything going ka-boom, run at your own risk etc etc)
2) Added a function to the 'Client Management Tool' that I created for the help desk to perform a full HW Inventory.This way, the operations team knew which machines were causing these warnings, they can pass the spreadsheet to the service desk who can then run the full HW inventory to clear these up.
Subscribe to:
Posts (Atom)