Jump to content


ITNinjaGuy

Established Members
  • Content Count

    7
  • Joined

  • Last visited

  • Days Won

    1

ITNinjaGuy last won the day on July 23 2017

ITNinjaGuy had the most liked content!

Community Reputation

1 Neutral

About ITNinjaGuy

  • Rank
    Newbie

Recent Profile Visitors

567 profile views
  1. Hi guys, We have set the region date and time settings via an attended answer file for a long time successfully in previous builds, however our 1709 build is showing the date back to front. These are the settings we have applied at OSD time: 7 oobeSystem=>Amd64_Microsoft-Windows-International-Core => Settings=> InputLocale en-Au SystemLocale en-AU UILanguage en-US UserLocale en-AU Is there anything super obvious that I am missing? Thanks in advance.
  2. Hi Grudd, I found the solution to my problem over on my post on the SCCM Subreddit page!: The logs didn't show any issues anyway :-( Thanks to Padgo I found one entry in the x64 area that was the culprit! So I deleted it and now everything works! What is strange about this is we have the most current 1702 Hotfix Rollup (KB4019926) applied which is supposed to fixed this issue... I'm doing some more investigation and testing to see if the issue reoccurs. To fix it, I had to run a couple of SQL queries to find a stuck record in the ConfigMrg database and then delete it. In the meantime, here are the screenshots and steps I followed: Disclaimer: Cation should always be exercised when editing the SCCM/ConfigMrg database directly and you should always have a working backup regardless of these steps. I am not responsible for any damage that may caused when doing these steps! Finding the ID's of the Unknown Computers (x86 & x64): (You need to copy value from the SMS_Unique_Identifier0 field for each record and run it for each Unknown computer type (x86 & x64) This is the entry (the culprit) that I found (this will be different/unique in every environment ) Copy the value as mentioned about and run it against each value and see if you get a result. If you get a result, it means that you have a stuck record. if not than it might be a more common problem/gotcha as i mentioned in my original post above. In my case I did have a returned vaule so I went about deleting it. This is how I deleted the entry: Note: its worth running the select unknown machines (built in) query as shown here at the top of this image to confirm that everything is still in order. I will continue to test by imaging a handful of machines and try deleting them afterwards to see if the issue still occurs. As for why it happened, I'm not exactly sure but when I checked with the other guys in my department, apparently that machine went flat during imaging (laptop). This has been an excellent learning curve and I will document this one in length in case it happens again in the future.
  3. Also I have looked at things in the database such as this: SCCM 2012 R2 – No Task Sequences Available http://www.mcgowan.id.au/blog/sccm/sccm-2012-r2-task-sequences-available/
  4. Hi everyone. I'm hoping someone out there can assist. Sorry for the length post but my aim is to provide as much information as possible to eliminate any of the common gotchas. ConfigMgr is 1702 with latest Hotfix I've spent the better part of two weeks trying to figure out why OSD has all of a suddenly stopped working. It seems to have happened around the same we upgraded our last DC from server 2012 to 2016 (swing migration) and raised the domain fictional level from 2012 to 2016. From the many hours spent doing google kung fu, ConfigMrg should not have any issues working in 2016 etc. DNS, DHCP AD are all reporting healthy with the usual couple of things that we can ignore from the BPA (Best Practices Analyzer). How we do OSD: We exclusively image Unknown Computers and have done so for many years (Since 2012 R2). We do not image our machines using deployments to any other collection. We delete the computer from the SCCM DB when we need to re-image. This works well for us in our environment. :-) All Task Sequences are deployed to the Unknown Computer collection. We are using ADK 1703 (the most recent one with all bug fixes) and boot boot x86 and x64 boot images are distributed and enabled but we only use the x64 boot image. The issue: Machines can successfully PXE Boot into WinPE, all machines no matter make, model, physical or virtual) all get an IP address and we can ping the ConfigMrg server without any issues. Once a computer gets into WinPE the screen goes blank and the computer reboots straight away. Actions taken so far: Common gotchas I have checked: Checked the date and time are correct on the client Made sure to delete any unknown computers or any references to the machines I have been using for testing or imaging in general Thinking that it might possibly be a Boot Image/PXE related issue I followed a couple of very detailed guides online and removed the PXE role from the Distributions Points by: Unticking it from each DP, deleting the files in the Windows Temp folder, deleting the RemoteInstall folder, removing the Boot images from DP's, the usual reboots, checking logs, re-enabling the PXE roll on DP's rebuilding the Boot images, deploying the boot images, enabling the both x86 and x64 boot images, making sure that my Task Sequences were referencing the newly created boot images. I then booted a machine up (in this case a test VM) and pressed F8, I ran cmtrace and opened up X:Windows\Temp\SMSTSLog\smsts.log. Then I found this error message: There are no task sequences available to this computer.. Please ensure you have at least one task sequence advertised to this computer. Unspecified error (Error: 80004005; Source: Windows) TSPxe 12/07/2017 12:28:40 PM 1284 (0x0504) So I thought perhaps my Task Sequence deployments themselves might have some issue on the DP's. I tried redeploying the task sequences and creating a brad new Task Sequence to test and I still got the same error. I checked the boundary groups and Active Directory Sites and Services and everything looks fine. I tried initiating a discovery of everything possible. Here is an example screen capture video of the issue we are experiencing: Looking forward to any comments below!
  5. Hey guys sorry for the delay. I found the problem in our environment! It turns out that deleing the account DefaultAccount was causing it to lock up...for what reason I just don't know. We disabled this step and our workgroup based Task Sequences are now working properly. I have a gut feeling that Microsoft are now using this built in account for other things where as it was just an erroneous in the past.
  6. Hey guys this issue has been driving me crazy the last week or so. It seems work fine with our Win10x64 1703 Domain Task Sequence but not our Win10x64 1703 Workgroup Task Sequence (it stays at Just a sec forever). We are ConfigMgr 1702, ADK 1607. It does kinda have a OOBE feeling to it and I have tweaked a couple of settings such as SkipMachineOOBE but not getting anywhere! I have a feeling that there is either a patch or something like that in my build or a bug with the ADK? Does anyone else have some suggestions?
×
×
  • Create New...