Jump to content


Established Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About ABAdmin

  • Rank

Profile Information

  • Gender
  • Location
  • Interests
    Computers, Computers & Smart-tech
  1. Just to cover the basics - have you changed any rights on the folder shares where you are fetching the packages? And are you sure that the account that you are using has the needed rights? As we recently discovered - changing / hardening rights and permissions can have unintended consequences ;-)
  2. I've gone through the configuration of the site to confirm that boundaries, groups and discovery are correct. I've confirmed that HTTP/80 is the preferred communication and that clients do not need to use HTTPS, SHA or encryption to communicate. Clients are able to ping and access the file shares of the MP. As a test, I disabled to the Windows firewall, but that did not help. At this point I believe the problem to be with the management point itself as clients are returning Code 0 on completion of the install. I believe the installation is correct and that the issue is with communication,
  3. Hi, I am hoping someone here has had a similar issue or can at least point me in the right direction to get my clients installing completely with usable components. The environment: SCCM 2012 Current Branch 1606 (5.00.8412.1307) - installed on a single machine (small production environment) Client version on server (5.00.8412.1307) Client computers: Windows 10 - all machines were recently updated to Windows 10, some via a SCCM TS, others via a USB SCCM TS. In either case, the same image was used. The problem: Newly installed machines are not receiving a usable SCCM client. Th
  4. And now I remember - the 0x80070005 is also tied to anonymous access. I had that when trying to deploy application updates through the Software Centre client. When the access was not enabled I would get a popup with that error msg. The same setting for "Allow clients to connect anonymously" should resolve it for you. Looking at your other error, the literature seems to indicate it may be a spelling\naming error ( "https://social.technet.microsoft.com/Forums/systemcenter/en-US/45683766-2370-41f5-b2a0-87bd16984664/sccm-problem-task-sequence-install-software" ) Perhaps this will help...?
  5. Hei, For the Errors: 0x80041002 & 0x80070005 I have not encountered these before, but will look around and see what I have. But for the final error: 0x80070002 - I have had this before and it stemmed from a rights issue. Basically the machine client was not authenticated to access the TS. I had to enable "Anonymous Access" and then my (new\unknown) machines could see the relevant TS during PXE deployments. Setting is here: Did not have "Allow Anonymous Access" enabled. Enabled it and OSD TS worked. Typical. To enable: Administration > Distribution Points > Propertie
  6. hei, Never had that error. Have had (0x80070032) but that was for a partitioning error in my target client. VMs are one of the easiest clients to capture...if everything goes right! ;-) What is the sequence of events that you are doing? What are your logs telling you? Can you give some more contextual information?
  7. If you access the share on the SCCM server (should be "\\SCCMServer\SMS_<SiteCode>") one of the available folders will be Client. From here, just run the ccmsetup.exe and it will install the correct client version onto your target pc. If its to only install one or two machines, then accessing from here is ok. But if you need to distribute the client to many machines, you can use a GPO that forces an install at start on all the machines. Set the GPO to run once so that you do not force an install of the client at every pc start.
  8. Hei, Have had this error before and found two possible solutions. 1 is here: http://social.technet.microsoft.com/Forums/systemcenter/en-US/0c957eaa-b600-4fc5-b620-f7219a048b52/os-deployment-failed-to-get-client-identity-80004005 The other was the BIOS clock of the target pc. The target had an incorrect date\time to the server and so could not autthenticate. Changed the clock to be closer and all was well. But are you sure on the error code? Looking at your logs, the error here is 80072EE7 and points to a HTTP error. Looking at the first error line, it would seem that the c
  9. Thanks Paul. I am leaning towards a full rebuild for the SCCM infrastructure, SQL server included, but finding the best option based on other's experience would be helpful.
  10. Morning, I have the opportunity to upgrade my SCCM 2012 SP1 server base OS to Server 2012. In addition, I now have the capacity to spread the load of the SCCM server across multiple SCCM servers. But before I dive in, I would like to know a few things that do not seem to be well documented. Has anyone tried to Upgrade a Server 2008 R2 to a Server 2012, with said server being an SCCM 2012 server? What were Your results\impressions? Would it be better to setup new servers instead? I aim to spread the various SCCM functions over several machines (until now, 1 server has been doing ALL
  11. Wonderful stuff...and right before quitting time too! Managed to get the distribution service working again as it should... What I did: 1. Removed all failed\in progress distributions & content locations 2. Backup up server 3. Remove distribution role from server 4. Reapply distribution role 5. Distribute content 6. Deploy content And it works. Its questionable if all that is required is the reapplication of the distribution point, but I am not going to try that from the backup. Also, I have not yet tested the PXE service...but I'll leave this til after the long w
  12. One dp - combined with the main SCCM server. Going through each individual object in each category under Software Library and am removing all distributions that are either "in progress" or "failed". Once done going to redistribute some to see if they go through.
  13. Should I cut my losses and rebuild all my libraries? Some Background: Over the past week I have been trying to redistribute and validate all packages, applications and OSDs to our SCCM server. The reason for this is that one of the hdd for the server was relocated from one virtual datastore to another. Unfortunately we discovered after the fact that SCCM could no longer validate the hash of any of the packages - each and everyone was listed as unavailable. I set about redistributing them and validating them, but now I am faced with the situation that the process to validate\redistribu
  14. Got it working! Found the solution here: "http://social.technet.microsoft.com/Forums/en-US/configmgrosd/thread/6a25e331-2705-4cba-bf2c-bb7d9f16ebef/" The Bios clock was wrong. Checked mine and sure enough - the clock was set to 4 May 2007. Setting it to the correct date fixed the issue! Machine is now loading in the OS.
  15. Update: Ok, on some advice from a guru I deleted all my boot images except the two defualt original images. Refreshed these to the distribution point and then ran an OSD TS. And guess what, all the client types that had been giving me issues before (and which I had treated as seperate items) booted up the TS and loaded the OS completely. All except this dx2250...which might soon become an airborne variant. The OSD TS was tested against the following: VMware Lenovo L520 Lenovo M90p Lenovo M91p Dell D531 HP 6710b HP dx2250 I managed to ge the debug DOS prompt to load before the r
  • Create New...