CCampbell

So, I had a working SCCM server for about 3 years and somehow managed to completely break it within the past month. I'm working on fixing the errors I'm finding in logs bit by bit. As of right now, in my SiteComp.log I'm getting a few curious errors. From what I've gathered, the Sitecomp.log has information pertaining to the SMS_Notification_Manager, SMS_WSUS_Control_Manager, SMS_WSUS_Sync_Manager and SMS_Site_Component_Manager all of which are in critical state on my server. I've tried doing a clean reset of the site, reinstall of SMS and the MP. In the sitecomp.log I'm receiving the following: Failed to make a network connection to \\SMS SITE SERVER\ADMIN$ (0x35). SMS_SITE_COMPONENT_MANAGER 10/11/2017 10:50:13 AM 5912 (0x1718) ERROR: failed to access server "SMS SITE SERVER", probably because the machine is down, the network is down, or the Site System Installation Account is misconfigured. CSiteSystemInstallationAccount::Connect() returned 0x80070035: The operation completed successfully. SMS_SITE_COMPONENT_MANAGER 10/11/2017 10:50:13 AM 5912 (0x1718) From what I've looked into, the "SMS SITE SERVER" usually enumerates the actually Site code.. Mine is listed as above, so I'm kind of assuming that it may be misconfigured somewhere? Any input on where to start here?

Yes, I have the Windows 10 Drivers in the boot file. This is how I've done older models, so I know it's an odd way to do it but it does work. Honestly, I've had no luck with cab packs from Dell, maybe it's just me not understanding it. I did manage to get one PC to image using this. Though I found some inconsistencies (like no model # listed in caption in any of the four devices) I was able to successfully use the vendor ID and the Microsoft Catalog driver seems to be working okay-- albeit at this moment it's hand loaded. Once this PC is finished with the OSD I'll see if I can use that driver to get the rest completed without having to manually load it in the CMD prompt. I thank Rocketman and Peter33 for the assistance. I'll see what happens here after I mess with the drivers a bit.

I install the drivers on an identical machine I hand loaded and then pull them out using DoubleDriver. I get those drivers from Dell and Intel, neither of which worked appropriately. My procedure may be a bit odd but it's worked on the rest of our system and it's what was left to me when I started with nearly no knowledge of SCCM. 2012 R2 with the 1511 update.

The PxeGetPxeData failed error is the most notable for me. I found a technet article on it possibly being a DHCP/self-assigned address issue. But if I enter the CMD prompt and do an IP renew I get "The operation failed as no adapter is in the state permissible for this operation." It still sounds like a driver issue to me, but I've went back again and reinjected the newest drivers into the boot image.

Managed to get the log. smsts.log

We recently began purchasing an updated model of laptop as they discontinued our older. Specifically Dell E5570's. I'm attempting to do an OSD on the laptops and keep running into the same issue. I don't believe my SCCM server is misconfigured or non-working because I can still deploy an OSD to the older models with no issue. I can load the boot image okay. Once I load into the OSD, I get "Windows is starting up..." and then "Preparing network connections". Afterwards all dialogues disappear and after about 2 minutes the laptop restarts. When trying to access the log, I open the CMD prompt and attempt to map a drive so that I can copy it. I get a "System error 1231 - network location cannot be reached" when trying to map the drive. However, I've tried injecting every iteration of network driver available into the boot image. I know that it's most likely a driver issue-- but are there any recommendations on how to fix it if every available driver from the OEM doesn't seem to work? Is there an alternate way to load a driver?

Move as in it automates the moving using a domain admin account to move the record to the target OU. Deleting the record earlier in the task sequence is also an option, but also requires the use of a script - of which I'm a bit more hesitant with deleting of a record especially when I'm struggling with the moving of one. I'm gonna keep giving it a look to see if I can find an alternative as this is the only thing holding me up now. Thanks for the help and quick reply.

Hello, I'm trying to image existing machines to Windows 10 which also includes moving to a separate OU. I understand from my bit of Googling that an SCCM TS is unable to move OU's through normal tasks for exisiting device records. I found that it is possible through a VBscript, however this seems to be where I'm running into an error. I can't find a definitive guide on how to use this. I used a script found over at http://blog.coretech.dk/jgs/vbscript-move-computer-object-to-another-ou-via-command-line-parameter/ The script is: I changed the two LDAP:// addresses to the OU where I wish to move it and saved it as a VBscript. I moved it to my sources folder and created a package. Creating a package is usually where I get hung up, truthfully. To create the package I: Checked source files, pointed it at the folder containing the VBscript. Choose to create a "Standard Program". I name it, set the command line as "cscript Move.vbs" have it run minimized, whether or not a user is logged in and with administrative rights. I then finish up the package. I've then inserted it into the TS as seen in the pictures below. I believe I'm probably just messing up at one or two avenues and it's causing me 4-5 hours worth of wait. (I have to image back to W7, customize it a bit and then run the W10 TS in hopes USMT functions as intended.) The task sequence is failing when it gets to that step with an error of 0x80004005 per the log. I can successfully image back to Windows 7 without an error, so I know it's not a laptop configuration issue but assumingly my OU move error.

So I've been having a bit of a weird issue since I began deploying machines with my most recent image/TS last August. Basically, any machine that has this that most recent image/TS reboots every morning. The users open up the laptop, login to their desktop and a popup says "rebooting in 30 seconds for updates" or something very similar and finally then reboots. Since we have network folders/printers and most users can't get their head around the need to restart every so often I figured this wasn't all too bad and if someone asked I'd tell them it was intentional. A few days ago I had a user log a ticket with some issues on their laptop. They were running the old image/TS from August 2014 and since the issue was BSOD's I figured deploying the newer TS with newer drivers embedded would fix their issue. So while the BSOD's went away they now have the daily restart. All this is to say that it is some type of configuration that exists within the confines of our SCCM configuration and not elsewhere like GP. We're running SCCM 2012 R2. I've checked through the TS, Boot Image, Client Configuration Settings and can find no root cause in those places. I'm not looking at it at this second but there is a setting in Client Configuration Settings to prompt for a restart when software updates are deployed, but even that is set to 60 minutes. I've combed through system logs on a computer directly after it restarted, nothing of note. I've checked all of our deployed applications/packages and triple checked that none are set to force a reboot if software installation falls outside of a maintenance window Is there somewhere else I can look or check to try to find a root cause? As I begin preparing for another refresh this upcoming summer I would like to know what's causing this to happen.

Looks like a failure to reach your sources folder. <![LOG[Successfully loaded the BCD boot system]LOG]!><time="15:42:33.978+480" date="01-29-2016" component="CaptureSystemImage" context="" type="1" thread="740" file="bootsystem.cpp:1082"> <![LOG[Connection request for "\\SCCORE01\Sources\WDS\OS\Captures"]LOG]!><time="15:42:34.103+480" date="01-29-2016" component="CaptureSystemImage" context="" type="1" thread="740" file="tsconnection.cpp:208"> <![LOG[Connecting to "\\SCCORE01\Sources\WDS\OS\Captures"]LOG]!><time="15:42:34.103+480" date="01-29-2016" component="CaptureSystemImage" context="" type="1" thread="740" file="tsconnection.cpp:268"> <![LOG[Failed to connect to "\\SCCORE01\Sources\WDS\OS\Captures" (86). Retry in 11 seconds.]LOG]!><time="15:42:34.431+480" date="01-29-2016" component="CaptureSystemImage" context="" type="2" thread="740" file="tsconnection.cpp:353"> <![LOG[Failed to run the action: Capture the Reference Machine. The specified network password is not correct. (Error: 80070056; Source: Windows)]LOG]!><time="15:43:31.650+480" date="01-29-2016" component="TSManager" context="" type="3" thread="844" file="instruction.cxx:911"> Are you putting in the the credentials as domain\username?

I think I solved it, at least to my knowledge, testing and the logs show. I changed from "All User Profiles" to specific settings and put in the miguser.xml and migapp.xml (with no configuration to either.) Bit more testing to do, but I did a refresh of the machine and the puppies I put on the desktop were retained.

Thanks for the quick reply. I double checked the package, which I had copied from C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\User State Migration Tool to my sources folder. Since I'm working with 64 bit systems I was concerned with the amd64 specifically. Migdocs.xml was both present in the above location and my sources folder.. which package MP7000B1 is the USMT package I created. Is there anything else I can check? I found a post on Technet detailing the error, specifically saying; But I was under the assumption that the Task Sequence would account for that.

Hello, In prep for a Windows 7 to Windows 10 migration during the upcoming summer I'm attempting to get the USMT up and running. We're running SCCM 2012 R2. I've followed a good bit of the guides available up until this point and I believe my TS is semi-correct. Basically, for my TS I made a new TS through the Wizard and chose to implement the steps suggested through the Wizard for Migration. I then just customized the rest of it. There was some mention of an XML file needing to be created, but from what I took away I didn't need to do this in R2 or if I simply just wanted all profiles. Seen here: Anyway, I ran the TS with that sequence on my test machine that I had some test files on, etc. From what I was able to tell the capture state had worked okay, but going back through the logs I guess I had been wrong. So here are the logs from the test machine-- Scan State Log: Load State Log: Anyway, I guess where I'm at is that I'm just confused as to what is causing my issue. I've looked into Errors 27 and 28 and there's not much more to it that isn't explained in the logs there. Is there something more I need to fix in the TS so that it can reference a script file (probably that darned XML)?