Jump to content


mikey090txx

Established Members
  • Posts

    6
  • Joined

  • Last visited

mikey090txx's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. After long hours of checking all possibilities and testing different recommendations we found that somehow over the weekend, the TLS had been disabled which once this was enabled we were able to launch the console without any errors. I guess for future and any others experiencing issues, check TSL also
  2. All- We recently upgraded our ADK to support win 10 ver 1809 and SCCM console ver to 1810. Everything was working as expected and then starting this Monday, we are not able to pxe or access the console via remote computer or directly on the server. We are on a 2012 R2 Standard server (no sp) running SCCM 2012. The server is online, all services are running, SQl server is hosted on another box and is working properly. All accounts have access and are members of the admin groups and SMS groups as well. I checked for any applicable updates that my have been missing and installed them. One of our techs was troubleshooting the issue and uninstalled and re-installed the console client and I believe that i may have another issue on my hands. All of the admin files used to exist under D:\Program Files\Microsoft Configuration Manager and now i also have files in C:\Program Files (x86)\Microsoft Configuration Manager. The C directory does not have all of the folders that exist in the D drive and the smsadminui.log errors are different that the log on the D drive. I checked the log files and get the following details which really don't give us much to go on from the SMSADMINUI.log in the D drive Error Code: ProviderLoadFailure \r\nSystem.Management.ManagementException\r\nProvider load failure \r\n at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode) at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext() at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryResultsObject.<GetEnumerator>d__74.MoveNext()\r\nManagementException details: instance of __ExtendedStatus { Operation = "ExecQuery"; ParameterInfo = "SELECT * FROM SMS_Site WHERE SiteCode = 'GPO'"; ProviderName = "WinMgmt"; }; \r\n [5, PID:4632][12/04/2018 09:29:54] :System.Management.ManagementException\r\nProvider load failure \r\n at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode) at System.Management.ManagementObject.InvokeMethod(String methodName, ManagementBaseObject inParameters, InvokeMethodOptions options) at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.ExecuteMethod(String methodClass, String methodName, Dictionary`2 methodParameters, Boolean traceParameters)\r\nManagementException details: The following is the error from the log in the C drive: [4, PID:5676][12/04/2018 13:59:12] :The performance counter '# exceptions' was not found [4, PID:5676][12/04/2018 13:59:12] :The performance counter '# result objects in memory' was not found [6, PID:5676][12/04/2018 13:59:12] :The performance counter '# images' was not found [1, PID:5676][12/04/2018 13:59:13] :The performance counter '# images' was not found
  3. Keilamym- Well seems like I went at this in all directions except for one of the smallest possible thing that could break a pxe execution, Drivers/Bios. This new model of machine that we just received is having an issue and is causing all kinds of problems with PXE. Seems like others are having problems all over as well and we only use legacy config in our environment and don't use UEFI.
  4. Keilamym- Yes, the log file that I am referring to is the smspxe.log file. I did confirm that the boot.wim file that it is pulling is the latest GPO one that I created and it does have the pxe option enabled in the properties. I removed the pxe option from the DP, then re-enabled it and now the WDS service is gone. I am going to try and recreate the folder and see it that helps as the remoteinstall folder exists but some of the subfolder are empty, the images one which may point to the root cause.
  5. Keilamym- Someone else had started trying to update the adk etc so I was just backtracking the steps to find out what had been done etc. I confirmed that the ADK was installed successfully and that the server also had the version installed that it needs. I ended up running the winpe cmd to copy the x64 and x86 winpe files and created new boot images to use. I am still getting the same issue, I can get the machine to pxe, I am presented with the background image that we configured in the boot.wim properties but the sequence fails at that point. Looking into the logs I don't see anything that jumps out at me. All updates are applied (adk/console) and the images are distributed. I have removed the pxe option from other wim files that we have and we are not currently deploying any other tasks or images with older or different boot files. It is as the task sequence selection is not initiated. Typically we would get the password prompt and then after that the window with all of the available task sequences
  6. Hello All- We have been using sccm 2012 for some time and have been imaging our devices with different task sequences and applying windows 10 1709. We decided to update our OS image to user 1803 as our base image on all of our task sequences. I followed a few walkthroughs and updated the ADK and WinPE on the server, updated the SCCM version to match the ADK update and imported the OS image and also created an OS upgrade package. I then selected the boot image that we had and ran the update distribution point and selected to Reload using the server's ADK version. The issue that we are having is that when we try to pxe boot, the sequence starts and communicates with the SCCM DP, then shows that it is loading the boot file. We get presented with our custom background image but then it delays for a bit and "times out" and just goes back to the starting point. * After this update the pxe process seems slower than before*
×
×
  • 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.