Jump to content


  • 0
miiike

Failure on Request State Store

Question

I continue on getting the following error when trying to request a state store in a capture task sequence.

 

The error that I am seeing on the SCCM when running the task sequence from the computer.

 

SMS State Migration Point failed to read the SignedSerializedSMPKey from the registry on computer SCCM. Possible reasons are SMP certificate is not yet signed by Site Server.

 

 

Additionally the SMSTS.log from the client has the following

 

Received 1298 byte response.	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
SMP request to "SCCM" failed with error: E_SMPERROR_ENCRYPTKEY_EMPTY (103)	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
0, HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\osdsmpclient\smpclient.cpp,2564)	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
ClientKeyRequestToSMP failed (0x80004005).	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
ClientKeyRequestToSMP( m_sSMPServer, m_uPort, m_ClientInfo, sKeyInfo ), HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\osdsmpclient\smpclient.cpp,1743)	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
ClientRequestToSMP::DoRequest failed. error = (0x80004005).	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
Request to SMP 'SCCM' failed with error (Code 0x80004005). Trying next SMP.	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
FALSE, HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\osdsmpclient\smpclient.cpp,1698)	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
Failed to find an SMP that can serve request after trying 4 attempts.	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
pClientRequestToSMP->Execute(migInfoFromMP.saSMPs), HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\osdsmpclient\smpclient.cpp,2713)	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
ExecuteCaptureRequestSMP failed (0x80004005).	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
ExecuteCaptureRequestToSMP(migInfoFromMP), HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\osdsmpclient\smpclient.cpp,2755)	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
ExecuteCaptureRequest failed (0x80004005).	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
ExecuteCaptureRequest(), HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\osdsmpclient\main.cpp,72)	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
OSDSMPClient finished: 0x00004005	OSDSMPClient	4/7/2010 3:47:07 PM	1256 (0x04E8)
Process completed with exit code 16389	TSManager	4/7/2010 3:47:07 PM	3532 (0x0DCC)
!--------------------------------------------------------------------------------------------!	TSManager	4/7/2010 3:47:07 PM	3532 (0x0DCC)
Failed to run the action: Request State Store. 
Unknown error (Error: 00004005; Source: Unknown)	TSManager	4/7/2010 3:47:07 PM	3532 (0x0DCC)

 

This is SCCM SP2 R2 on a Server 2008 R2. I have already checked all pre-reqs for WebDav and IIS, have removed and reinstalled the State Store (several times), and have run a Site Reset with the Network Access Acccount and the Admin account.

 

It seems that I may just be missing some sort of registry key? I thought doing a Site Reset would fix this but no go.

Share this post


Link to post
Share on other sites

Recommended Posts

  • 0

Hello,

I apologize for posting on an old topic, but this fits the issue I have been having recently. It sounds like you got the issue resolved however I am unable to resolve mine.

 

I am trying to run a Re-Image task sequence (Windows 7 to Windows7). I have multuple error codes in the smsts.log file. The main one that I believe is causing the issues is "Failed to run the action: Request State Store. The request is not supported. Error: 80070032" But I also have the 80004005 error. Attached is my task sequence and the log file. Hopefully you can provide some insight because I am at a loss.

 

The SMP storage has "everyone" set to full control right now as a test, therefore I know it's not a SMP permissions issue.

 

Thanks in advance for any help, it's much appreciated.

smsts.log

Re-Image Task Sequence.xml

Share this post


Link to post
Share on other sites

  • 0

Although not necessarily a solution, I have noticed that checking the "When no local distribution point is available, use a remote distribution point." box under the Distribution Points tab for the deployment of the task sequence resolves the error that no SMPs are found.

 

My initial thought is to be careful with that check box though, as you may find your systems using a DP that is across a slow link.

Share this post


Link to post
Share on other sites

  • 0

Although not necessarily a solution, I have noticed that checking the "When no local distribution point is available, use a remote distribution point." box under the Distribution Points tab for the deployment of the task sequence resolves the error that no SMPs are found.

 

My initial thought is to be careful with that check box though, as you may find your systems using a DP that is across a slow link.

 

Thanks, Devtrends! I did 2 changes:

 

Set the option you suggest about "When no local distribution point is available, use a remote distribution point." and also I set Full Control NTFS permission to the "Local Service" account to the folder set as the backup/restore folder. Then it all began working.

 

As I did 2 changes, I am not sure if both are needed or just 1 of them, but anyway, this solved it and I don't want to touch now to re-test. :)

 

Regards,

 

Jose Angel Rivera

Share this post


Link to post
Share on other sites

  • 0

 

Thanks, Devtrends! I did 2 changes:

 

Set the option you suggest about "When no local distribution point is available, use a remote distribution point." and also I set Full Control NTFS permission to the "Local Service" account to the folder set as the backup/restore folder. Then it all began working.

 

As I did 2 changes, I am not sure if both are needed or just 1 of them, but anyway, this solved it and I don't want to touch now to re-test. :)

 

Regards,

 

Jose Angel Rivera

I've had similar issue. Adding LOCAL SERVICE with Full Control to the store fixes it for me, but every 24 hours SCCM resets the permissions.

Share this post


Link to post
Share on other sites

  • 0

Folks, I dug deeper in the issue.

My Client is on a subnet that is properly in the boundary group of the server below.

So,

Client : 192.168.51.150
SMP: 192.168.51.50

These are properly bordered in the SMP role, but still the smsts.log fails with:

Number of local SMP's = 0    OSDSMPClient    23/02/2018 03:39:40    2080 (0x0820)

 

SMP Location Info = 
<SMPLocationInfo>
    <Sites>
        <Site>
            <SMPSite SiteCode="XX1" MasterSiteCode="XX1" SiteLocality="REMOTE">
            <LocationRecords>
                <LocationRecord>
                    <ADSite Name="SITE1"/>
                        <IPSubnets>
                            <IPSubnet Address="192.168.51.0"/>
                            <IPSubnet Address=""/>
                        </IPSubnets>
            <ServerName>http://server.company.intern.com</ServerName>
                </LocationRecord>
            </LocationRecords>
            </SMPSite>
        </Site>
    </Sites>
</SMPLocationInfo>

 

So, I changed the Task Sequence to be allowed to fallback on a Remote DP and that worked so this is the root of the problem.

Possible causes:

a. The client is in two Boundary Groups, one via the AD Site and one via the IP Subnet 
b. Dual network interfaces exist on the client so it gets confused
 

I will look into both issues.

 

--

Alex

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...



×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.