Jump to content


TimLancer

Established Members
  • Content Count

    15
  • Joined

  • Last visited

  • Days Won

    1

TimLancer last won the day on May 15 2014

TimLancer had the most liked content!

Community Reputation

3 Neutral

About TimLancer

  • Rank
    Member

Profile Information

  • Gender
    Male
  1. I use Shavlik Patch with SCCM. In order for it to work I deploy a self-signed certificate and registry setting to allow these updates from WSUS. It works great. If I import the certificate and make the registry modification in an OSD TS, it installs the third-party updates during Apply Updates as well. My issue is with Build & Capture. If I try the same method it fails with a certificate not trusted error - but this used to work with SCCM 2012R2. I used to be on SCCM 2012R2 SP1 and was able to run my Build & Capture TS with an Apply Updates step. I know that the client will see all updates offered by WSUS (SCCM SUGs do not apply) and I could see in the logs and it would silently fail on just the third party updates published via Shavlik because it didn't trust the certificate. It was the best of both worlds because I could get my (fairly static) Office updates and it would ignore the (updated quite often) Shavlik ones. After I upgraded to SCCM CB, my Build & Capture TS halted at the Apply Updates step because the certificate wasn't trusted. I'm not sure what caused this behavior because I upgraded SCCM, MDT, and the ADK to the latest versions at the same time. If I disable the Apply Updates step the Build & Capture TS works fine. Any ideas why during OSD installing the cert fixes the certificate not trusted error - but during Build & Capture the same process does not? The only big difference I can think of is that the B&C machine isn't on the domain. Does anyone bypass their local WSUS server and go out to Microsoft Update? I already have Windows updates installed via Offline Servicing but I'd love to avoid installing the same 30-40 Office updates every time. I figure if I bypass my local WSUS server then I might bypass this security certificate warning.
  2. Anyone else seeing weird issues with Windows 10 OSD specifically towards the end of the process? I'm not positive if this occurs after the first reboot or not - but it seems to be consistent across different hardware for me. Deleted ALL my boot images and started with fresh x86 + x64 boot images created from Windows 10 ADK (non-MDT) Use that x64 boot image to deploy a Windows 7 image and I don't have any issues during OSD. Able to hit F8. Use that same x64 boot image to deploy a Windows 10 image and at some point during OSD I sort of lose my mouse pointer and the ability to press F8. HOWEVER I can see the focus changing if I ALT+TAB and/or click with the mouse so it's not like the devices are dead. Anyone else not able to hit F8 towards the end of their Windows 10 OSD?
  3. I don't know your particular setup, but typically clients would get their DNS server addresses via DHCP. So you'd want to go into AD DHCP and change the DNS Server addresses from the old address to the new one. Then when clients refresh their DHCP lease they'd get the new DNS server. Servers typically aren't set up for DHCP so you'd need to change the DNS server settings manually. If you only have a handful of servers I'd just use the GUI. If you have a ton of servers or just want to complicate things you could certainly script it with powershell commands.
  4. Sant- You should probably start a new thread when you have a question unrelated to the original post. Yes, it is possible. Niall wrote a great guide for it here http://www.windows-noob.com/forums/index.php?/topic/5542-how-can-i-easily-prompt-for-a-computer-name-in-configuration-manager-2012/
  5. As a follow up, I was able to deploy my existing task sequence pointed at the Windows 8.1 .WIM file to my "problem" Lenovo Helix 2 and it finished successfully. Since I don't have an option to disable UEFI on my Helix 2 I guess I'll be deploying Windows 8.1 on them for now. Once Windows 10 is available on the volume license site I plan on using that instead. Originally I planned on ignoring UEFI/Secure Boot until Windows 10 came out but now that I have this Helix 2 I am no longer afforded that luxury. Thanks for posting Joe and of course thanks Niall for being awesome (as always). If you're thinking about deploying Windows 7 x64 onto UEFI enabled hardware with no Legacy/CSM option - think twice!
  6. Could this be about Windows 7 + the vendor's implementation of UEFI on specific models? Sorry - I don't have any Dells here to test with, we're a Lenovo shop. Even though my main concern is about imaging this Lenovo Helix 2 (which doesn't have a CSM/Legacy option) for troubleshooting purposes I decided to use a machine that I have been able to successfully deploy to in the past. I wanted to separate any potential issues with UEFI in my shop from issues that might be specific to the Helix 2. My test subject is a Lenovo ThinkCentre M73 Tiny (10AY-001YUS) that originally shipped with Windows 7 x64. It supports both the legacy BIOS and UEFI (with a CSM option). UEFI: On / CSM: On = Windows 7 SP x64 OSD succeeeds UEFI: On / CSM: Off = Error If I use the *same* Task Sequence that fails above and change the "Apply Operating System" step to reference a Windows 8.1 x64 WIM instead of the Windows 7 SP1 x64 WIM, it deploys successfully! ...too bad my users hate Windows 8.1
  7. Joe- I suspect I'm having the exact same issue. I've been successfully deploying Windows 7 x64 via a SCCM (2012R2 SP1) task sequence to systems running a BIOS OR with UEFI in Legacy/CSM mode. Since it's been working so well for me I've avoided complicating things with MDT, UEFI, or Secure Boot....my problem is that I just got in a new Lenovo Helix 2 (20CG-000SUS) that does NOT have a Legacy/CSM option in the UEFI! For troubleshooting purposes I found a recent desktop system that is UEFI but has the CSM option. I can image with CSM off and get the same error as you do. I can go into the UEFI and turn CSM on, and the system boots fine. Post setup I can confirm the disk layout is correct and it's using GPT. Not sure what I'm going to do with my Helix 2 then...
  8. Thanks for the reply, Peter. I'll continue to focus on eradicating my yellow exclamation points. If one of the hardware models seems to be unusually slow or unstable I'll take your advice and go through each driver with a fine toothed comb. I thanked Niall in my original post but I've also learned a lot from all your great posts over the years. Thank you too!
  9. I'm a lurker on these forums so I'd like to start out by thanking everyone for their time and contributions. This is more of a general question in regards to chipset drivers and SCCM OSD - I'm not having a specific issue but I haven't found a satisfactory explanation on chipset drivers anywhere yet. Like many others here, I've been installing Windows for a long time. It didn't matter what kind of system you had - after you finished installing Windows the FIRST thing you did was install chipset drivers and reboot. Always. Fast forward to today. I'm following the excellent sticky'd guides ( <3 u Niall) and not having a problem with drivers...but something has always bothered me. For instance if I download the Intel chipset drivers for an Ivy Bridge chipset and blindly import them all into SCCM I end up with around 72 drivers. I know you're NOT supposed to do that (and I haven't). So instead I followed the suggestion of installing Windows 7 fresh. Then I'd manually install the chipset drivers and use Device Manager to drill down into each 'unknown device' that now has a driver to determine what the underlying .sys file is for that specific chipset component. Then I'm importing just that specific chipset driver into SCCM...so I'll end up with 1-3 chipset drivers on average per chipset. Seems nice and clean but there is always this nagging doubt in the back of my head that there *might* be some components using built-in Windows drivers (hence no Unknown Device) but might run better with the official Intel drivers. Are any of my concerns real?
  10. Thank you so much for the encouraging words, Mikey C. I hope other lurkers in this forum can benefit from this post.
  11. No apologies necessary! And again - thanks! I was hoping for any reply, let alone one from the guru If I take that captured WIM file, import it, and then Deploy with a TS everything seems to go fine! After the image is brought down the system comes up and the SCCM Client is installed and configured for my organization. Now that you say it's not big deal I feel a bit silly about over analyzing it. I wanted to avoid a potential scenario where my image was 'sort of' broken and I deployed anyway - and then had problems down the line. I'd hate to deploy to 1,200 clients today and not have a problem until down the road when I try to do an upgrade or something. This is all stemming from nightmares of setting up a hardware agnostic image in the Windows XP days - ignoring a sysprep error that didn't SEEM to hang up the whole process could come back later to really screw you over.
  12. Just to take DHCP out of the equation, I manually specified an IP address during my Build & Capture sequence. I hit F8 during the sequence and confirmed it was using the static I specified and was able to nslookup and ping. I am getting the same name resolution error in my logs as I did before. Disappointing, but at least I eliminated DHCP as a variable in this issue. Right now I'm out of ideas on what to try next. Am I weird by actually looking at my SMSTS.log file? Are other people considering the fact that an image goes up and the VM reboots into Windows (well that little mini-setup wizard) as the process being 100% successful? Right now with my almost-vanilla TS I'm able to install Windows, apply updates, install applications, and put an image up. Should I just ignore my errors and deploy?
  13. Additionally can anyone tell me if it's alright to remove the Apply Updates and Capture The Reference Machine steps? I'd like to accelerate my testing process, right now I'm making some changes, crossing my fingers, and then coming back hours later to see if it worked. If I remove Apply Updates and Capture The Reference Machine then I'll be able to see my failure faster. Obviously no updates will be applied and no image will be put up - but that doesn't seem to be the root of my problem. I saw in front of the TS today and waited for it to finish the 'Prepare OS' step. I hit F8 right then at that second, and a nslookup failed. Here's the fun part - an ipconfig showed that DHCP was OFF, yet the adapter had an IP address (the IP it had the last time it obtained a lease) *and* I could ping anything I wanted by IP. If I specified a server in the nslookup command I got back a result. So why would it no longer be on DHCP -after- the sysprep but before the capture? I thought this was supposed to be the easy/automated part
  14. Long time lurker, first time poster. Niall, your guide has been invaluable and Microsoft is lucky that people like you exist in the community. I'm sure it's a lot of hard work without much thanks - so THANK YOU! I followed your SCCM 2012 guides to setup a fresh install of SCCM 2012R2 Update 1 on a VM running Server 2012 + SQL 2012 + MDT 2013. My goal is to have a Windows 7 64-bit 'fat' image with Office 2013 + all Windows Updates installed that I can then use in a separate Deploy sequence. I am using a standard TS and not a MDT TS for the Build & Capture because I read somewhere that it was easier to use the standard to Build & Capture sequence to capture and then the MDT sequence to deploy. If I follow your Build & Capture guides for Windows 7 (also referencing the Windows 8 one because I'm using the install.wim method) everything APPEARS to go successfully. No errors appear on screen during the Build & Capture sequence and an image file is created. However after the image is created and the Build & Capture machine reboots, I'm asked to enter a computer name, an administrator password, time zone, etc. All things that I thought were spelled out in the Build & Capture task sequence. This makes me nervous that something isn't working properly behind the scenes. Additionally the root of C: still has a SMSTSLog folder. Digging through the SMSTS.log, I can see several failures that usually indicate a problem with DNS. I'm confused at how I have network during 99% of the process but then name resolution fails *right* after the Prepare OS step? I'm using VMware 5.1 and the VM is a standard Windows 7 64-bit template using the e1000 adapter. It's my understanding that the e1000 adapter works in all the recent flavors of WinPE. DHCP is running on a Server 2003 machine in the same subnet as the SCCM server and VM and DNS entries are correct in the scope and in the DHCP Server Options. I'm able to hit F8 during the Build & Capture sequence and I can verify the IP is correct, I can nslookup against the SCCM server, and ping. Things I've tried so far: * Recreated my boot files just in case (with ADK 8.1) and updated my DPs * Deleted all my TSes, and OS Installers * Download a fresh Windows 7 Enterprise with SP1 64-bit from Microsoft's site and imported it again * Created a new Build & Capture task sequence. The only modifications I made to the stock SCCM Build & Capture sequence are: Modify the 'Partition Disk 0 - BIOS' step so it only creates a single primary partition (not using BitLocker) and setting SMSMP=mysccmhost.domain.local * Resetting the SCCMNA password * Creating an SCCMNA2 account and specifying it under the Software Distribution Network Access Account tab (based on other folks' experiences) * Deleted the Build & Capture VM's device out of the collection and re-added it * Recreated the Build & Capture VM from scratch Any ideas at all? I spent the past two days going line by line through your guides again double checking everything I've done. smsts.log smsts.log
×
×
  • Create New...