Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Sunday, July 8, 2012 10:36 AM
Hello,
We recently migrated from sccm 2007 to 2012. The problem is when i deploy TS (win 7, wim file ~40 GB) to workstation with small ssd drive (128 GB) and check access content directly from a distribution point when needed by the running task sequence, task statrs sucessful> formating C:> Apply OS (tooks a
while)>Apply image 1 of 1 (after passing ~90%)> error message 80070070 - There is not enough space on the disk. (Error: 80070070; Source:
Windows) > Good!, after that workstation continiusly rastarted itself with error Unexpected restart. OK now i found this in server silde logs:
file C:\SMSTaskSequence\Packages\TLV00014\7v61.wim
WIM error:C:\VM Machines\Windows XP Professional\Windows XP Professional.vmdk.
There is not enough space on the disk. (Error: 80070070; Source: Windows)
WIM error:C:\Windows\winsxs\x86_microsoft.vc80.mfcloc_1fc8b3b9a1e18e3b_8.0.50727.6195_none_03ce2c72205943d3\mfc80CHS.dll.
There is not enough space on the disk. (Error: 80070070; Source: Windows) Unable to apply (0x80070070)
Installation of image 1 in package TLV00014 failed to complete..
There is not enough space on the disk. (Error: 80070070; Source: Windows)
Entering ReleaseSource() for C:\SMSTaskSequence\Packages\TLV00014
reference count 1 for the source C:\SMSTaskSequence\Packages\TLV00014 before releasing
Released the resolved source C:\SMSTaskSequence\Packages\TLV00014
InstallImage( g_InstallPackageID, g_ImageIndex, targetVolume, ImageType_OS,
g_ConfigPackageID, g_ConfigFileName, bOEMMedia ), HRESULT=80070070
(e:\nts_sccm_release\sms\client\osdeployment\applyos\applyos.cpp,470)
As we see this file 7v61.wim (40 GB) was downloaded locally even though access content directly was checked and so he did not have enough space to extract and apply it.
In the sccm 2007, we have not encountered such a problem.
I cant understand why wim file steel downloaded locally, and how to prevent that.
Thanks
Andrey
All replies (9)
Sunday, July 8, 2012 11:37 PM ✅Answered | 3 votes
you need to change your Deployment of the task sequence to 'access content directly' instead of 'download...', this setting is a drop down menu available in the properties of the Deployment, click on the Distribution Points tab.
Note: If you only see 'download' then you need to make sure that each and every package referenced in the task sequence has the following setting on the Data access tab selected "copy the content of this package to a package share on distribution points"
cheers
niall
Step by Step ConfigMgr 2007 Guides | Step by Step ConfigMgr 2012 Guides | I'm on Twitter > ncbrady
Monday, July 9, 2012 8:45 AM
Hi Niall,
Thanks for the reply,
I see booth options 1. download and 2. access directly, so every time if i change the deployment i choose access directly (little bug in gui you know).
Access directly was alredy checked/enabled. In the proof of this i dont see downloading 7v61.wim when the TS is running. But there is long pause in Applying OS step (immediately after formating disk) with just one progress bar, seems like it's download procces, after this pause i see 2 progress bars second - Applying image 1 of 1.
Thanks
Tuesday, July 10, 2012 2:29 PM
Niall,
I am looking at the same issue with a client. But my system in my lab shows the Access content directly... selection and none of my distrbution points have the share feature enabled for packages.
Why do we need to copy the files to a share? The smspkgd$ is a share.
Mike Brown
Tuesday, July 10, 2012 10:22 PM
Niall,
I am looking at the same issue with a client. But my system in my lab shows the Access content directly... selection and none of my distrbution points have the share feature enabled for packages.
Why do we need to copy the files to a share? The smspkgd$ is a share.
Mike Brown
If you look at SMSPKGD$, it is actually empty by default. The only time that packages will be there is if you enable the package option "Copy the content of this package to a package share on the distribution points."
In CM 2012, content can only be accessed through HTTP. So, even though there is a share on the DP for SMB access, the share is empty, unless you select the option to populate the share.
Thursday, July 12, 2012 1:12 PM
In my test environment, I have all of the packages and applications distributed to a distribution point share and I am able to set the task sequence deployment drop-down to "Access content directly..." - however if I apply my changes and re-open the deployment it shows as being back to "Download..." - is this a bug in the GUI? My task sequence does seem to run from the DP.
Thursday, July 12, 2012 1:56 PM
Have you checked smsts.log if it really downloads the Wimfile?
I also noticed the bug in the GUI, i have changed to Access content... a couple of times and now it seems to stay to Access content...
Thursday, July 19, 2012 1:21 AM
In my test environment, I have all of the packages and applications distributed to a distribution point share and I am able to set the task sequence deployment drop-down to "Access content directly..." - however if I apply my changes and re-open the deployment it shows as being back to "Download..." - is this a bug in the GUI? My task sequence does seem to run from the DP.
I get the same behaviour, I'd say it's a bug!
Wednesday, February 13, 2013 7:51 AM
Shawn Porter bosted this nice blog article about the issue on my http://myitforum.com/myitforumwp/2012/05/16/configmgr-os-deployment-run-from-distribution-point/
This t-sql query will list all of the packages which a Task Sequence references that DO NOT have the "copy the content…" option enabled. However it does NOT show the OSD objects like Boot Images, OS Images, and Driver Packages.
Declare @TaskSequenceID char(8); set @TaskSequenceID = 'XYZ00000'
select P.PkgID, P.Manufacturer, P.Name, P.Version, P.Language, P.PkgFlags, (128 & P.PkgFlags)
from v_TaskSequenceReferencesInfo as TSR inner join vPackage as P on P.PkgID = TSR.ReferencePackageID
WHERE TSR.PackageID=@TaskSequenceID
and (128 & P.PkgFlags) <> 128 --the bitmask for the "Copy the content... option in the Package Data Access properties"
Wednesday, March 6, 2013 4:02 PM
@Chad Simmons - After reviewing my OSD Build and Capture task sequence and after making the OS Image and Boot Image available on the SMSPKGC$ share I was still having the same problem with my PXE Boot clients. I took a look at the Shawn Porter blog post and created a new package for the Configuration Manager client and I am hoping that will resolve my PXE Boot issue. The problem I have with this is that it seems like this is a fairly substantial issue with the OSD process in SCCM 2012. The fact that packages aren't really intended to be shared via the SMSPKGC$ location and that some folks have been able to get PXE booting to work without sharing the content tells me that I must be missing something. What is it that is causing some people to have to revert to the old way of handling OSD through direct access to the DP and others don't seem to have the same experience? Naill's guides have been excellent so far and he doesn't seem to recommend going this route. I will post again after I get the Config Manager Client (unlocked) package distributed and once again attempt to change my deployment to "access content directly from the distribution point". I am hoping that I will see the option and that it allows me to resolve the issue so that my PXE boot VM doesn't just get stuck after the boot up and wallpaper load.
Thanks again,
Chris Bolton
EDIT: After updating my distribution point the option was available on the task sequence however it did not resolve my problem. I can successfully boot my workstation VM via PXE and the pre-password steps initiate with the final one being "Preparing Network Settings". This step clears and the VM sits with the SCCM 2012 wallpaper for a few moments and then the VM reboots. I am never prompted for a password and I don't see anything that would indicate an error. I even went so far as to integrate the VMWare tools drivers into the boot x86 and bott x64 image in the event there was a problem there.
2nd EDIT: I found my answer through reviewing my own notes. My issue came from using the VMXNET3 NIC instead of the E1000 for my VM. As soon as I switched to the E1000 and rebooted I didn't have any issues pulling the task sequence and building my image. If anyone else out there is working within VMWare be sure that your test workstations are using E1000 adapters (at least while you are trying to image them).