xc3ss1v3

Update... I've seen it mentioned to ensure that McAfee is turned off or at least excluding file. I paid no attention to this as we aren't using McAfee. Fortunately, I was doing some folder maintenance while logged into our Central Administration Site and I decided to start another boot image import while watching the DISM log. Low and behold, I see a pop-up from Bit-9 asking if I wanted to allow or block DISM.exe from executing. So, because I was working from the console on my machine previously, I never saw this pop-up which eventually timed out and defaulted to block... Thank you security guy. Once I allowed the processes to continue, the image upload completed successfully. I really hope others stumble onto this thread and others like it. It seems many security applications are set to at least prompt for DISM.exe.

Digging a little deeper, I think the problem might be with DISM. There appears to be a broken mount point. I could just be chasing my tail here, but maybe that could cause this? Unfortunately, whoever did that has since deleted the original source location and so, trying to cleanup the mount using /cleanup-wim fails. Is there anything I can do to remove this? Can I simply delete the folder in C:\windows\temp\bootimages running as SYSTEM?

Good morning. It seems I have lost the ability to import and update boot images. I first noticed this while trying to add network drivers to my x86 boot image. Thinking that the image was simply corrupt, I decided to start a fresh one. Unfortunately, I cannot do that. The error I'm receiving states "You can not import this boot image. Only Finalized boot images are supported." I've tried using the boot images stored in %ProgramFiles%\Microsoft Configuration Manager\OSD, and images pulled from Windows ADK. Any suggestions?

For anyone visiting this topic, I was able to resolve by recreating the bootable image

Good morning folks. I've ran into an issue that I first thought would be simple (seen it before, kind of), but has grown into a larger issue. In a remote office, an IT Point of contact tried to re-image a machine and got a failure in WinPE while the system was looking for available task sequences. I've seen this happen before and it's typically because either the machine isn't in a proper group/task sequences not advertised properly or the client machine's date and time are way out of sync. Unfortunately neither was the case. Where it grew into a larger problem is that 3 other office in different locations are all experiencing the same error. That got me thinking, "network problems." I've worked with our operations team to ensure that any blocked/dropped traffic was being allowed through. They have now verified that there is nothing but accepted traffic between the client and the management point. So now, back to square one. For setup, the ITPOC's are using a network boot image on a bootable thumb drive. I can see in the smsts.log that there is successful communication between the client and management point just before the errors occur (see below). Is there a log that records policy requests for OSD? Any other troubleshooting steps would be greatly appreciated.

This is probably a dumb question, but I guess I never really thought about it. Does CcmExec.exe need to be able to run on the central admin site? Because, as of right now, it will not start.

Update: I seem to have stopped the constant error log creating in the SQL folders (for now). However, AD system discovery seems to still be broken. I've triggered a manual discovery, but nothing is ever written to the log file.

Yes, it is a server dedicated only to the CM databases. The OS is on a seperate disks from the databases, though the log files are not seperated. I feel like I can safely assume is the SCCM logs because of the folder location (not to mention it only hosting the CM databases).

Hey everyone. I've run into an issue where the log files located at \\SQLServer\Program Files\Microsoft SQL Server\MSSQL11.InstanceName\MSSQL\Log are not only filling up the hard drive, once it's filled, log files are continually written to the folder, just at 0KB each. I first noticed a problem when I no longer saw new systems being brought into the SCCM database after being joined to the domain and a system discovery cycle running. I looked at adsysdis.log for clues and found that the last discovery failed at the approximate time we had other servers (Exchange) have issues because of network problems. Those issues have been remedied, but since that time, nothing else has been written to the log file. I've attributed that to not being to run a discovery because of the issue noted above. For a brief description of the environment, I'm operating in a heirarchy with a Central Admin Site, Primary Site, and distribution points. There is a separate dedicated SQL server hosting a SQL instance for each site. I've done the typical, first reaction type things such as: backing up then clearing the log files, restarting the SQL services, restarting eacy site server and sql server, but none of it seems to resolve. I know this is vague, but I really was not sure where to start troubleshooting the problem from here without some pointers. Any help would be appreciated. Happy to supply log files as needed.

I thought about doing that, but how do you set the date? Because the second Wednesday isn't always after the second Tuesday. I'm sure there's a simple answer to that I'm not thinking of... I believe it's have to sync every hour, but I wasn't the one to set that part up, so I'll have to double check. And yeah I could definitely see that. Allows for time to remove trouble updates and such before deploying to the organization.

Hey everyone... Have a little bit of an issue. Well, not really an issue because everything works alright, but I'm guessing something is just configured slightly off. Like practically everyone, I have ADR's built to download and deploy the monthly updates from Microsoft. Currently, I have the ADR's set up to run on the second Tuesday of every month at 11pm. However, without fail the ADR will grab some or no updates. When I come in the next morning, I simply re-run the ADR and it pulls in and deploys the released updates. My first thought is that I have the time set to run before Microsoft releases the updates. But, in looking at the time released, they are at 12pm. I'm assuming that is 12 in the afternoon which would, obviously, be before 11pm. What am I missing?

Have you been able to get that resolved? Has anyone else run into a similar issue?

Good morning folks... Just would like to clarify a couple things with those of you who might have already installed the recent SP releases. My current installation is System Center 2012 R2 Configuration Manager. As I understand it, I'll need to install the file SC2012_SP2_Configmgr_SCEP.exe on both the CAS and primary site server since I'm using a heiracrchy. That will take my installation to System Center 2012 R2 SP1, I believe. Is that part correct? The next question is, and I assume this is right, since I've downloaded what MS is referring to as an evaluation, the installation will detect current licensing and take off the evaluation period? Thanks for your time.

For anyone that might run into a similar type issue, this most definitely was caused by there not being enough space on the C: drive of the CAS. After going in and cleaning out inetpub log files to free up space, the .wim file distributed successfully.

Could this be caused by there not being enough space on C: of the Central Admin Site to support the .wim file? I know I'm not distributing to that, but it seems I remember a copy of the file is created there when it's distributed to the Primary Site and DPs? I've gone further in testing with the Distribution Point Job Queue Manager, creating a simple package and distributing, then watching the DPJQM for results, which did come up. However, when distributing the .wim to a remote DP (one listed within DPJQM), no results every show up for jobs.