Archive for category windows 7 x64
During my project to upgrade all our Windows 7 Enterprise SP1 (64bit) devices to Windows 10 Enterprise 1809 (64bit), I ran into a compatibility issue during the task sequence. Windows 7 video drivers were detected as incompatible during the in-place upgrade to Windows 10, so I had to find a way to remove the drivers during the SCCM task sequence.
This is the batch file code I used to disable, then remove video drivers from the task sequence.
REM Driver is disabled
devcon disable =display
REM Driver is removed here
devcon remove =display
REM reg add command replaces whatever value is in the SearchOrderConfig with the appropriate value to tell the system NOT to go to windows update for driver updates
REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching /t REG_DWORD /v SearchOrderConfig /d 0x0 /f
REM Driver package is removed here
FOR /F “tokens=4 delims= ” %%A IN (‘devcon driverfiles ^=display ^| FINDSTR “Driver installed from”‘) DO devcon.exe dp_delete -f %%A
The following shows where in the task sequence I add the video driver removal step. Also, note that I have a step to copy devcon.exe utility which is not on Windows 7 by default.
I’ve extensively tested this on my DELL devices and it works perfectly.
While attempting to perform an in-place upgrade from Windows 7 Enterprise to Windows 10 Enterprise I came across Error Code 0x80004005.
Looking at C:\WINDOWS\CCM\Logs\smsts.log gave me the clues on the error message.
There are many posts on how to fix this particular error message; it seems that this error code is pretty generic and it shows up on several instances in many SCCM operations – this document particularly deals with a task sequence for an in-place operating system upgrade.
Since this was an in-place Windows upgrade, I needed to find out more detailed information and I was able to get it from C:\$WINDOWS-BT\Sources\Panther this folder contains a list of .XML files that collect compatibility data that is collected during the upgrade process.
I opened the last XML file and this gave me the actual clue as to what was failing during the upgrade process – video drivers were the culprit!
Now I know what’s going on during the task sequence and I can attempt to fix this issue.
I’ll blog about how to fix this issue in a new post, stay tuned!
There’s an issue with brand new installations of Windows 7. If you’re trying to patch/update a brand new Windows 7 installation, Windows Updates will sit there for days without patching anything.
It turns out that, a while back, Microsoft updated their patching servers and because of that, brand new Windows 7 installations will fail to patch until you install the following KBs:
Some of these KBs will not say that will not apply, but keep trying the others and one will fix the Windows Update issue with newly installed Windows 7.
A while back, I opened a Technet case on Microsoft’s forums and here’s the original link.
The following will allow you to run a Powershell script as a scheduled task. These instructions have been tested on a Windows 7 64bit computer.
Before proceeding, make sure your Powershell script runs without any errors. The best way to make sure your script is running fine is by calling it from a command prompt.
Note: Make sure you run Set-ExecutionPolicy from an elevated Powershell window to make sure your system (Windows 7) is allowed to run Powershell scripts.
- Open a Command Prompt window
- Run: powershell -file <your ps script file>
- Make sure it executes properly
Now, open Windows 7 Task Scheduler:
- In the Actions tab
- Power shell is found at: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
- You can also just use powershell.exe
- In Add arguments (optional) field, add the following: -File “C:\Path-to-your-script\Your-ps-script.ps1”
- Sample: -File “C:\Program Files (x86)\Info Folder\Get-Speed.ps1”
- In Start in (optional) field, add the following: C:\Program Files (x86)\Info Folder
- Sample: C:\Program Files (x86)\Info Folder
I’m not going to go over the other sections as this is the main section to be able to execute Powershell scripts from Schedule Tasks.
There are several blogs on this topic; however, some seem to be lacking one or more details or may not show how to patch and customize Adobe Acrobat Reader XI. In this blog, I will show you how to patch, customize and deploy, via SCCM, Adobe Reader XI (11.0.03).
Pre-requisite: Make sure you have installed Adobe Customization Wizard XI
- Download the latest version of Acrobat Reader from Adobe’s FTP site.
- The direct FTP link is: ftp://ftp.adobe.com/pub/adobe/reader/win/11.x/11.0.03/en_US/
- We’re going to download the EXE file: AdbeRdr11003_en_US.exe
- Next, from an administrator command line, we’re going to extract the MSI from the EXE file using the following command: AdbeRdr11003_en_US.exe -nos_o”c:\SomeDirectory” -nos_ne
- Do not close this command line window as we’ll use it again.
- For this example I’m extracting the contents to C:\temp\Adobe XI (11.0.03) folder.
- Once we’ve extracted the source files from the EXE file, then let’s run (as an administrator) the Adobe Customization Wizard XI to create the MST file that we’re going to use to customize Adobe Reader XI.
- If the customization wizard isn’t run as an administrator, you won’t be able to save the package.
- Basically, we’re going to make changes in the the following sections:
- Personalization Options
- Installation Options
- WebMail Profiles
- Online and Adobe online services Features
- Once the customization options have been completed, proceed to click on Transform menu option then click on Generate Transform…
- Save the MST file in the same folder where the Adobe Reader MSI exists.
- For this example, we’re going to save this file as AcroRead.mst
- Next, click on File and then click on Save Package.
- Back to the command line and let’s create an Application Installation Point (AIP) in order to patch Acrobat Reader.
- In the folder where the MSI file was extracted, you’ll notice that file AdbeRdrUpd11003.msp is located there – that’s our patch file that we’ll be applying.
- For this example we’re going to create a new folder – C:\AdobeAIP
- From the command line, in step 3, we’re going to create the AIP with the following command: msiexec /a AcroRead.msi
- Once the wizard comes up, make sure to point it to the folder created in step 8.2
- Make sure you run this command from the folder in step 3.
- Take a look at the files extracted
- Change directory to folder C:\AdobeAIP
- Now we’re ready to patch the Acrobat Reader source files, let’s use the following command: msiexec /a AcroRead.msi /p “c:\temp\Adobe XI (11.0.03)\AdbeRdrUpd11003.msp”
- This will open a wizard window; make sure there are no error messages during this task.
- If the patching process was successful, then we should now have a patched Acrobat Reader XI installation as well as a customization file.
- From Step 3 folder (C:\temp\Adobe XI (11.0.03)), copy the MST file to the Step 6 folder (C:\AdobeAIP)
- At this time, folder C:\AdobeAIP should contain a patched Acrobat Reader XI as well as the customization file. We’re going to use the contents of folder C:\AdobeAIP as our deployment files to create our SCCM 2012 deployment package.
- Copy all contents of C:\AdobeAIP to the share that SCCM uses to deploy applications in your environment.
- Let’s create a new application deployment package in SCCM. First, go to the Software Library section, and click on Application Management and then click on the Applications container to create the new package.
- Right click on the Applications container then click on Create Application option.
- Point to the network share where you copied the files in Step 15 and select the file AcroRead.msi
- You may get a warning message about not being able to verify the publisher of this MSI file, just click on Yes.
- In the General Information wizard screen, in the Installation program field, add the following:TRANSFORMS=”AcroRead.mst”
- This line should read: msiexec /i “AcroRead.msi” TRANSFORMS=”AcroRead.mst” /q
- Continue accepting defaults until the application wizard finishes.
- Now, you can deploy this new application to a selected number of computers or users.
Recently we started the deployment of Windows 7 Enterprise (x64) throughout the company that I work for. The targeted hardware were DELL Optiplex 980, 990 and 9010 model desktops. The nightmare began after deploying several Optiplex 990 models. We use Microsoft System Center Configuration Manager 2012 SP1 to deploy the OS and applications to these desktops.
After deploying over 20 Optiplex 990 models, we noticed that on some 990s we were getting continuous BSOD’s after a day or two (the BSOD’s also came after a week of having the computer in production!). After a desperate call to Microsoft, it was determined that the BSOD code was a generic hardware error code. However, Microsoft was unable to pin-point the issue after 3 weeks of troubleshooting!
The one thing that came to mind was that the recent models that I deployed were older model Optiplex 990 desktops (possibly 2012 and very early 2013 models) , but at that time I failed to look into this clue. Luckily, and I mean luckily, I was able to catch the culprit of this nightmare, and here are the screenshots.
Note: disregard the failed PCI driver controller installation
Basically, you’re looking at a hijacked SATA driver installation!
These DELL Optiplex 990 models come with a SATA drive and controller installed. As a matter of fact, when Windows 7 Enterprise gets installed, SATA drivers are loaded for this computer; however, sometime post installation Windows finds, or detects, an IDE ATA chipset and without any warning, it installs the Intel(R 6 Series/C200 Series Chipset drivers!
To make matters worst, I’ve configured the OS Deployment in SCCM to use native DELL drivers specific for this computer model, yet Windows Updates comes a day or two later and replaces them with the Intel(R 6 Series/C200 Series Chipset drivers.
The quick, and lazy fix, is to go to the BIOS and change the drive controller settings from Raid On (default setting) to ATA.
I’ve yet to identify the reason why this change in disk controller drivers.
This article is somewhat not complete, and it may contain some incorrect definitions, but it’s out there mainly for reference. Updates coming soon!
- Open Regedit and go to HKLM
- Expand HKLM\Select and look at the value of Current key
- Based on the value of Current key (1, 2 or 3), select the proper HKLM\System\ControlSet00x
- Expand HKLM\System\ControlSet00x\Control\Class
- Under Class you’ll get a list of drivers that load during the boot process of Windows 7
- In each driver entry, under the Class folder, look for the following keys: LowerFilters and UpperFilters – these are some of the drivers that load during the boot process