Jump to content


joeman1881

Established Members
  • Posts

    91
  • Joined

  • Last visited

Everything posted by joeman1881

  1. Thank you for the reply. What I just finished doing is I set a dependency in my gpo saying if the registry file showing config manager is installed is there, then do not point to the SCCM server for WSUS. Otherwise, point there. This seems to be working, however my machines that do have the client say there are no updates available when manually searching from control panel > Windows Update. Is this typical?
  2. Hello all, I have an issue that creeped up on me, and I have been too buried to go back an fix it. Now it's critical so I have been allocated time to fix it...... Basically I had my SUP working with weekly update deployments. I then broke these deployments by enabling a GPO that forced users to go to http://sccmserver:8530 for updates. The reason I did this is unless they searched online for updates...it always showed there were no available updates. The error I am seeing from the clients is: Group policy settings were overwritten by a higher authority (Domain Controller) to: Server http://sccm4:8530 and Policy ENABLED WUAHandler 4/4/2014 8:34:51 AM 9976 (0x26F8) Failed to Add Update Source for WUAgent of type (2) and id ({4A138D6C-12EE-4BC4-8D74-D5DCFC745EDA}). Error = 0x87d00692. WUAHandler 4/4/2014 8:34:51 AM 9976 (0x26F8) If anyone has a similar configuration please advise on best practice for configuring this. Thank you, -Joe
  3. Yes. I upped the speed to 1gbps, and let it run for roughly 20 minutes and the image was maybe 50% downloaded. I then switched back to unicast to try a deployment the old way, and I'm able to download the wim in less than 20 seconds. Apparently I was being greedy hoping for faster deployment. I should have probably timed it prior to making the changes.
  4. SO....Finally got around to enabling this and figured out a few network issues that were blocking multicast but I got it to work. Too bad it's wayyyy slower than running unicast deployments. Not sure what's causing the bottleneck. I looked around online and found a few similar complaints, but no fixes. There are registry adjustments that can be made but from the looks of it, they didn't make things faster than the standard unicast deployments. Anyone run into this issue in their environment?
  5. Thanks for the reply. I will talk to my desktop team and see if they'd rather try now, or do it later. They are deploying 4000 machines over the next 4 months. We only have 4000 machines right (800 of which are xp and coming out) now so it's going to be pretty hectic. I'll let them decide if they'd like to give it a shot.
  6. I have somewhat of a rookie question. I realized just recently that I haven't enabled multicast deployments from my DP. This whole time I was under the assumption that they were automatically enabled (silly me). Now that my environment is functional is there any reason why I wouldn't want to enable this feature? I have 1 other system that uses multicast in our environment, and it is used for streaming local TV channels to our different rooms. We have an epic dual 10gb connection to each of our sites so bandwidth/collisions shouldn't be an issue. Sometimes the techs will re-image a lab of 30-40 machines at one time, which is a scenario where I'm thinking multicast should be enabled. Any opinions on issues I may run into? Thanks
  7. Yes, they are all Microsoft Surfaces...I am just going to give up on this machine and send it back. As long as it's deploying to everyone else, I'm not really concerned. Thank you very much for all the responses!
  8. Isn't it odd that this is only occurring on one machine? I have other machines (same model) that are working fine and completing this TS without failure. The one device Microsoft sent me was properly deploying before, but after a couple times, it's decided to start failing all of a sudden. So bizarre.
  9. Ok, I will try putting it in a package and doing something similar then. I have other scripts we may be adding down the road so then I can just add them as you do in your environment. Not sure if I should open another thread, but have you ever run into issues with 8.1 deployments where it stops after the initial windows boot to ask for your connection (wireless select or wired)? As soon as I choose it carries on with the task sequence and continues installing windows. So bizarre.... Its related to this thread issue which is why I ask...
  10. Great. I finally figured this out this morning using the Powershell ISE utility. What a great tool! When you deliver this in a task sequence, are you just creating a .ps1 file and then running a command prompt to launch the Powershell file, or is it better to package the Powershell file and deploy that way? CMD seems like it would be better, but I'm not sure how well it would work accessing from a network share. Thanks again for the response.
  11. So....I'm having an issue getting this to execute correctly. Forgive me for my lack of Powershell knowledge. I need to update the last line obviously, but the 4th line, am I modifying #strAdminGroup, group to match the machines local admins group? Or just modify the last line? Thanks in advance!
  12. Thank you for this! I will add it to my deployment that I am about to test and report my findings!
  13. Update: I ran this task sequence on a virtual per a co-workers recommendation. It worked without a hitch. I will add the net localgroup command back in, and the faulty application and see what happens.
  14. Starting about a week ago I noticed an issue with PXE deployments. My task sequences are failing somewhere along the line, but I am not sure where. At first I thought it was related to my network card not installing correctly anymore so I rebuilt my driver package with the current release from MS (being that my primary test machine is a MS Surface). This didn't correct the issue. Then I noticed my command - net localgroup "Administrators" "DNAME\DOMAIN POWER USERS" /ADD - was failing. I then created a new task sequence but kept this step out because it was automatically failing the whole TS. The next issue I ran into was one of my packaged applications began to fail during deployment. After enabling "continue on failure" for my applications I was able to get my task sequence to deploy, but my driver package doesn't seem to have deployed correctly, my machine didn't add to the domain, and in turn, AV was not deployed. I have to be missing something super basic. I attached a copy of the smsts....Please help! smsts.log
  15. From what I am seeing in my console, the time my machines receive updates matches the "Run the rule on a schedule" time I configured in my automatic deployment rules. Have you configured automatic deployment rules yet? If not, the server will not know when to push these updates out to the specified collections. If not, there is a great tutorial here: http://www.windows-noob.com/forums/index.php?/topic/6799-using-system-center-2012-configuration-manager-part-9-deploying-monthly-updates/ I followed similar guidelines, but adjusted the powershell commands to only kick out the collections I needed.
  16. Do you run this on a schedule? If so, is it possible the latest time it ran that most of your machines were shut down? It says Unknown which to me means it cannot reach the machines to verify failure or success. If they are all unavailable (shut down, or not connected to the network) they will not receive updates thus bringing your percentage for the latest deployment down.
  17. It looks like your machine is having issues uploading your image to the network location you specified. You may want to verify the account your using to upload the final product has permissions to the share. This may seem obvious, but also verify you input credentials as "domainname/username" instead of just user name and password. Give that a try and let us know if that resolves the issues.
  18. Within SCCM I do. I was just receiving complaints from my techs because when they are installing a new build with office they have 65+ updates to do, 60 (roughly) of which are office. Another thing I thought about after repackaging was that even if I add the updates into the Updates folder of the install location, it still adds time to the install. If the updates are rolled into the software its no additional time.
  19. So I was able to get this to work after removing it from the Distribution point, and repushing it out, then deploying to my test group. For some reason, the updates that were on SCCM are still available from the past were still showing up when I would check for updates via Control Panel > Windows Updates. The solution to the problem? Download Office with SP1 included and re-package that for deployment. Going forward, if I want to add updates, do I just try to locate them in my WSUS folder and manually add them to my package "Updates" folder?
  20. I extracted this exe into my updates folder and reattempted deployment but no luck. I will mess around with it and update when I find the solution.
  21. Nice find! I will give this a shot and report back.
  22. How are you guys handling office updates pre-deployment. Right now I am deploying our copy of office 2013 directly from our MS Volume License because it activates via KMS. The problem is they don't keep this version up to date. So now when I deploy the application, it has 60+ updates. Has anyone found a work-around for this? I can't find a way to slipstream in updates like I can with offline management of .wim's. Thanks in advance
  23. Yes it was. Thanks for finally making me take a look at this! Microsoft Surfaces time/date has to manually be adjusted in the Windows OS in order to update the internal clock. Silly to go through oob experience just to update time, but whatever makes them work... Happy Friday!
  24. I saw this in another article, but I disregarded it due to the fact that the Surface doesn't have a user modifiable bios. Come to find the machines MS sent us for demo's were dated back to Aug 2013, and didn't sync with the Server because of it. This caused the machines not to find any active deployments. Setting up the OOB stuff for W8.1 and changing the time in the OS before PXE booting corrected the issue. Come to find the machines actually sync with MS regularly to keep the internal clock up to date. Thanks everyone for the notes.
  25. Still no luck. I attached the smsts log. Disregard the x.x. IP's smsts_clean.log
×
×
  • 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.