OSD Task Sequence fails on Deployment Point on different subnet -- seeking help

[JHBPJF]

I believe the issue why my OSD Task Sequence is failing is because this DP is on a different subnet /23 (255.255.254.0) rather then /24 (255.255.255.0). The sequence fails with 0x80070002 saying that "The system cannot find the file specified." even though it's there.

 

I've found the work around for my imaging process to continue is if I go to each of packages that fail (images, MDT toolkit files, usmt, boot images, etc.), go to it's properties, then the Data Access tab, and make sure that "Copy the content in this package to a package share on distribution points:"

This works great, up until I get to the package that SCCM created (I think) which is the Configuration Manager Client Package. I'm unable to select this option as everything is grayed out.

1. Could the subnet be the issue?
2. Is there a better fix?
3. Why is everything grayed out for the Configuration Manager Client Package.

[Rocket Man]

This works great, up until I get to the package that SCCM created (I think) which is the Configuration Manager Client Package. I'm unable to select this option as everything is grayed out.

 

 

You will have to re-create a new agent from definition and then you have that option.

 

EDIT: once done change the task sequence windows setup configmgr task to reference the new client package.

[JHBPJF]

 

You will have to re-create a new agent from definition and then you have that option.

 

EDIT: once done change the task sequence windows setup configmgr task to reference the new client package.

 

Going to give this a try right now. Thanks. I didn't think of it as just being a package pointed to a folder.

[Rocket Man]

 

Thanks. I didn't think of it as just being a package pointed to a folder

 

If it is what i think you mean from the above quote.....You do not create a standard package and point it to the source files for the new agent. You right click on the packages node and create a package from defintion and select the configmgr upgrade all 5.0 and finish off the steps, distribute to content share and then change the agent within the task sequence to reflect the new package.

[JHBPJF]

So that worked, but now applications don't install and there isn't a "Data Access" tab for applications. I'm using a UDI task sequence, and it's been stuck on Installing 1 of 8 programs for the past hour. I've set the Maximum allowed run time for this application to be at 30 minutes, so it is hung up some how, but nothing has thrown an error.

[JHBPJF]

Rocket Man - do you know why I need to do this in order to get imaging to work on this subnet/ip range at this plant?

[Rocket Man]

How have you configured your boundary? AD site name or IP subnet range?

As for the applications, they do install correctly individually as deployments as opposed to OSD tasks?

[JHBPJF]

How have you configured your boundary? AD site name or IP subnet range?

As for the applications, they do install correctly individually as deployments as opposed to OSD tasks?

 

We had a consultant do the work and he polled our AD forest and boundaries were created as well as groups. From what I can see, he created an IP address range for that plant, but I don't see it taking the subnet mask. Should I switch the IP address range to IP subnet? I read that IP subnet isn't good.

 

Yes these applications/packages deploy perfectly fine on 2 other DP's we have setup for other locations during OSD and don't run into any of these 0x80070002 errors.

 

They also deploy perfectly fine using Software Center.

[Jorgen Nilsson]

Hi,

No there is no need to change to a IP Subnet boundary, IP Address range is my prefered solution. If you are using "Access the content directly" it could be that BITS isn't installed and not working on the DP in question as Applications always is downloaded using BITS and never accessed using SMB.

Regards,
Jörgen