Jump to content


All Activity

This stream auto-updates     

  1. Yesterday
  2. I just did a deployment of software that deployed to over 90 machines successfully. But when I make a query to try to capture all devices with that software and version, it only pulls in 19 devices.All files and folders for the software update from old version to new have the exact same names and folder structures. I've tried a compliance baseline but it's not working either.How can I get a query to pull all the devices that have this software and version? I included the correct Software Inventory settings from what I know.Here is my query:select distinct SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client, SMS_G_System_INSTALLED_SOFTWARE.ProductName, SMS_G_System_INSTALLED_SOFTWARE.ProductVersion from SMS_R_System inner join SMS_G_System_INSTALLED_SOFTWARE on SMS_G_System_INSTALLED_SOFTWARE.ResourceID = SMS_R_System.ResourceId where SMS_G_System_INSTALLED_SOFTWARE.ProductName like "My%Software" and SMS_G_System_INSTALLED_SOFTWARE.ProductVersion = "5.9.1"
  3. Introduction You are most likely familiar with the Microsoft Surface Pro 6 and the recently released version of Windows 10 version 1903 (May 2019 Update). Now you can automate the installation of Surface Pro 6 using PowerShell and MDT. This script has been written to allow you to automate the deployment Windows 10 version 1903 (May 2019 Update) using the latest available software including: Windows 10 x64 (version 1903) Microsoft Deployment Toolkit (MDT) build 8456 Latest available 2019 drivers for the Surface Pro 6 for Windows 10 version 1903 Windows 10 ADK (version 1903) Windows Server 2019 Note: This is fully automated, and as this does install a Windows Deployment Services server role hosting a boot image, you should modify the script accordingly and test it thoroughly in a lab first. This script is tailored for one thing only, deploying Windows 10 x64 version 1903 to the Microsoft Surface Pro 6 with all drivers loaded and MDT pre-configured. Download it and customize it to suit your needs for other hardware if you wish because what it does is pretty cool. This script performs the following actions:- Downloads and then Installs Windows ADK 10 (version 1903) if you have not done so already Downloads and then Installs MDT, if you have not done so already Downloads all required drivers for Microsoft Surface Pro6 if you have not done so already Imports the Windows 10 x64 (version 1903) operating system into MDT Imports the Microsoft Surface Pro drivers into MDT Creates Selection Profiles for Surface Pro 6 and WinPE x64 Creates a Deploy Windows 10 X64 version 1903 task sequence Edits the Deploy Windows 10 X64 version 1903 task sequence and adds an inject drivers step for Microsoft Surface Pro 6 Sets a WMI query for hardware detection for the Surface Pro 6 on the corresponding driver step Injects the Microsoft Surface Pro 6 network drivers into the LiteTouchPE_x64.wim Creates custom CustomSettings.ini and BootStrap.ini files Disables the X86 boot wim (as it is not needed for Surface Pro 6) Changes the Selection Profile for the X64 boot wim to use the WinPE x64 selection profile Installs the Windows Deployment Service role Configures the WDS role and adds the previously created LiteTouchPE_x64.wim Starts the WDS service so that you can PXE boot (UEFI network boot). All you have to do is provide a domain joined server (MDT01), then download the script below, modify some variables, then place certain files in the right place such as the Windows 10 x64 Enterprise (version 1903) media. Please ensure you have a working DHCP scope on your Active Directory domain controller, then PXE boot a Microsoft Surface Pro and sit back and enjoy the show. Step 1. Download the script The PowerShell script will do all the hard work for you, download it, unzip it and place it on the server that is designated to be the MDT server. Scripts.zip Step 2. Configure the variables in the script Once you have downloaded and extracted the script, you need to configure certain variables interspersed throughout the script. I'll highlight the ones you need to edit. The most important of them is the $SourcePath variable (line 57) as this decides where to get the content from and where to store it. This variable should point to a valid drive letter, the folder name will be created if it does not exist. The $FolderPath variable (line 271) specifies the MDT Deployment share root folder for example C:\MDTDeploy. There are other variables to configure, for joining the Domain (lines 349-351) and then you need to configure how you actually connect to the MDT server from WinPE (lines 426-430) Step 3. Copy the Windows 10 x64 (version 1903) operating system files Mount a Microsoft Windows 10 x64 Enterprise (version 1903) ISO and copy the contents to $SourcePath\Operating Systems\Windows 10 x64\1903 as shown below. Step 4. Optionally copy MDT, ADK 10, Surface Pro drivers This is an optional step. If you've already downloaded the above files then place them in the source folder, otherwise the script will automatically download them for you. Note: You do not have to do this as the script will download the content for you if it's not found. Step 5. Optionally copy your Applications to the respective folders This is an optional step. If you have apps like Office 365, copy them to their respective folders under Applications. If you do add any applications, you'll need to edit the corresponding section within the script for the CustomSettings.ini and replace the GUID for the App, these applications are remmed out with a #, as shown here (line 392-393) and in line 328 Step 6. Run the script On the server that will become your MDT server, start PowerShell ISE as Administrator. Click on the green triangle to run the script. This is how it looks while running... Below you can see the script has completed. Step 7. Deploy a Surface Pro 6 After the script is complete, you are ready to test deploying Windows 10 version 1903 (May 2019 Update) to a Microsoft Surface Pro 6. You can see that Windows Deployment Services is installed and that the ADK 1903 version of the MDT LiteTouch_X64 boot wim is already imported. This boot image also has the Surface Pro 6 network drivers added. After the Surface Pro 6 has PXE booted, you'll see the MDT computer Name screen, you can change that behavior in the UI itself (CustomSettings.ini on the Properties/Rules of the DeploymentShare) or automate it via the many methods available such as those that Mikael describes here. After clicking next the OS will get deployed. and after a while it's all complete. Step 8. Review the MDT Deployment Workbench After opening the Deployment Workbench, you can see the Deploy Windows 10 x64 version 1903 task sequence is created and in the task sequence you can see the inject drivers step that is customized with a wmi query for Surface Pro 6 drivers specific to the Surface Pro 6 are imported into MDT Surface Pro 6 specific selection profiles created drivers (network) are also added to the x64 boot image Troubleshooting If the script has issues starting WDS (and you see the error below) then restart the server, as you were asked to do at the end of the script ;-). If you cannot PXE boot, because WDS is not accepting connections (revealed by the PXE Response tab in WDS properties), then look for the following error in the scripts output: An error occurred while trying to execute the command. Error Code: 0x5 Error Description: Access is denied. If you see that error, then the user you are logged in as does not have sufficient permissions to configure WDS. To grant permissions to the Windows Deployment Server (MDT01) do as follows Open Active Directory Users and Computers. Right-click the OU where you are creating prestaged computer accounts, and then select Delegate Control. On the first screen of the wizard, click Next. Change the object type to include computers. Add the computer object of the Windows Deployment Services server, and then click Next. Select Create a Custom task to delegate. Select Only the following objects in the folder. Then select the Computer Objects check box, select Create selected objects in this folder, and click Next. In the Permissions box, select the Write all Properties check box, and click Finish. Next, open ADSIEdit.msc Browse to the Computer Account of the WDS Server. It will have a Child Object named something like "CN=MDT01-Remote-Installation-Services". The user that runs the the PowerShell script or the WDS Console needs Full Access permissions to this Child Object. Right click and choose Properties. Select the Security/Permissions tab and add the user/group in. Set them to have Full Permissions. Log out of the MDT Server and log back in again. AD replication may delay the result of this, but you should now no longer have Access Denied. Summary Automating the deployment of Windows 10 version 1903 (May 2019 Update) to the Microsoft Surface Pro 6 using PowerShell and MDT is easy when you know how.
  4. Diskpart List disk select disk 0 clean convert gpt create partition efi size=200 assign letter=s format quick fs=fat32 create partition primary assign letter=c format quick fs=ntfs exit
  5. You need to format your disk using diskpart list disk select disk 0
  6. Hi All, I have a question if anyone can help. I have 2 different offices (Office1 and Office2). Both have a local DP and both are PXE enabled. Our current DHCP config is setup as: Office1 - 192.168.10.x There a Microsoft DHCP server (local DP) that issues 192.168.10.x addresses to all clients in Office1, If you perform a PXE boot form within this office, it will download the boot image from the local DP in this office. All good here Office2 - 192.168.20.x A IP helper on the router is forwarding all requests to the DHCP server located in Office1 192.168.10.x. The scope for this office is 192.168.20.x. Therefore all clients within this office have IP addresses starting 192.168.20.... Again so far so good. My issue is that when i perform a PXE boot from with Office2, it is downloading the boot image from Office1 and hence awfully slow. I understand that the IP Helper is directing all requests to the DHCP server in Office1, but what i want is to ensure that once the 'DHCP issued' IP address is received by the client in Office2, then that client should be downloading the boot image from the local DP in Office2, not downloading it from the DP in Office1. Once the task sequence starts, all the content needed for imaging (wim, apps etc) is downloaded from Office2 correctly, its just that initial download of the boot image that comes from the wrong office. Is there anyway i can configure PXE or DHCP to say if a client from the 192.168.20.x subnet sends a PXE request, then forward this to the local DP located in Office2? I am aware of DHCP option 66/67 but avoiding this route as this restricts us as its either UEFI or Legacy. Thank you all.
  7. Last week
  8. Hi, Been all over the net, can't find anything at all in relation to this. Brand new 1902 setup on 2019 server -- and I can't get PXE boot working whatsoever. Always getting: Configuration Manager is looking for policy. I've tried the countless suggestions here and elsewhere, and i still can't fix it. Here's my SMSPXE.log I've rebuilt the boot image, ensured boundaries and all else work. I can deploy an application to systems, so I'm sure my boundaries are right, not sure what else i'm missing? Thanks, smspxe.log
  9. I recently upgraded my SCCM environment to 1902, I then did a 1903 Feature update to a laptop which was successful. I made the Products and Classification change in SCCM to make Windows 10 1903 software updates available. I created a deployment packed that included 1903 updates and deploy it to a combination of Windows 7, 10 1803 and 1903 devices. The Windows 7 and 10 1803 devices applied the updates successfully but both of the 1903 devices are giving me a message in software Center that there are "Insufficient Permissions for Software Installation, Your IT department has set restrictions for this software that prevent it from installing on your computer." Has anyone else run into this?
  10. Hi, I have upgraded SCCM from 1802 to 1902 and Applications no longer install within the Task Sequence has anyone else experienced this? I am also having issues with PXE: RequestMPKeyInformation: Send() failed. PXE::MP_InitializeTransport failed; 0x80004005 PXE::MP_LookupDevice failed; 0x80070490 PXE Provider failed to initialize MP connection. Element not found. (Error: 80070490; Source: Windows) PXE has been reinstalled on the DP Several Times looks like more of a MP issue though Any Help will be much appreciated. (I have logged a ticket with MS premier Support) Thanks
  11. I just updated our Windows 10 image with the newest 1903 version. Previously in my 1803 image, I used a cmd to turn off User Account Control during the task sequence using the following: cmd.exe /c reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v "EnableLUA" /t REG_DWORD /d 0 /f That had been working just fine. I took the exact same OS Task Sequence and just changed the OS image package and now every user, including administrators, are prompted when an .exe runs. (specifically whoami) which puts username, IP, ect on the desktop which makes supporting these devices much easier. Running other .exe's don't bring up this prompt from what I can tell so far. I verified UAC is actually set to not notify. Why does this app bring up the notification every time?
  12. I get this error. The file do exist in the folder... How to fix this?? Server 2012 R2
  13. Hello! Can someone advise me how can I configure MDT Deployment Workbench Monitoring for SCCM MDT Task Sequences? I went through the guides online, and they ask to create a new Deployment Share in MDT - but I already have an existing SCCM MDT Task Sequence and content, so I won't be using the MDT's Deployment Share. Nonetheless, I created a Deployment Share in MDT, and also enabled Monitoring, however - There is no option to select 'what' is monitored (which logs folder/SCCM task sequence) Nothing appears even after completing some task sequences Can it even monitor SCCM MDT task sequences? Or it can only work with MDT task sequences (no SCCM)?
  14. can you attach your ztigather.log and any other applicable log so i can take a look.
  15. Calling all SysAdmins: WIN on Altaro’s 10th Anniversary! #SysAdminDay To celebrate their 10th anniversary & SysAdmin Day 2019, Altaro is giving SysAdmins and IT professionals the opportunity to share their best IT story and WIN fantastic prizes! Throughout our careers, we all gather daily stories worth telling, from tech situations to funny anecdotes, terrible mishaps or incidents with our colleagues. This year everyone is invited to share their best stories for a chance to win big prizes: an amazing Royal Gourmet BBQ Grill, a GPS Drone with Camera & Live Video 1080 HD FPV, a GoPro Hero5 Waterproof Camera & more. And here’s a tip: for any eligible subscription they give a guaranteed Amazon eGift voucher! So, if you are a Hyper-V or VMware user, download Altaro’s VM Backup and follow the instructions you will find over here to WIN these exciting prizes! Enter the competition & make it a year to remember by sharing your best IT story! Good luck!
  16. what i meant was to browse the location on your pc where customsettings.ini was referenced, does the file indeed look correct, contenwise?
  17. i only have the 1, i have searched through the entire server trying to find another one. When i have looked at the logs i can see it is running through the rules but is still no applying
  18. are you sure it's looking at the customsettings.ini that you created or another one..
  19. Hi, I have the below custom setting file. The issue is it is not being applied on my builds. When i check the logs they state that the file has been processed successfully. Its like the rules get completely ignored [Settings] Priority=Init, ByDesktop, ByLaptop, DefaultGateway, Default Properties=ComputerLocationName, ComputerTypeName, ComputerSerialNumber [Init] ComputerSerialNumber=#Right("%SerialNumber%",10)# [ByLaptop] SubSection=Laptop-%IsLaptop% ComputerTypeName=L [ByDesktop] SubSection=Desktop-%IsDesktop% ComputerTypeName=D [DefaultGateway] 192.168.1.1=blanked 192.168.1.1=blanked 192.168.1.1=blanked [Blanked] ComputerLocationName=blanked [Blanked] ComputerLocationName=blanked [Blanked] ComputerLocationName=blanked [Default] OSInstall=Y ComputerLocationName=XXX ComputerTypeName=X OSDComputerName=%ComputerLocationName%%ComputerTypeName%%ComputerSerialNumber% SkipCapture=YES SkipAdminPassword=YES SkipProductKey=YES SkipComputerBackup=YES SkipBitLocker=YES
  20. Hi all, It's been a little while since I posted on here! Hope everyone is doing good! I'm after some advice on SCCM and Default Apps being reset on deployment... it's a bit of a weird one, so bear with me! I'm running the latest SCCM CB version (1902 w/o the hotfix). I've been deploying Windows 10 Pro 1809 with it. This is a custom image from the Windows 10 ISO, installed, apps all installed, then used the SCCM Capture Media to take a copy and deploy. Following the deployment (lack of user testing as well), we've now started to notice the users custom settings are not being honoured when logging back in. For example, if you set the default browser to Chrome, log off and back on, it's set back to Edge. Same for Adobe with PDF's, and also Default Printers as well... Now, the weirdest part is that this doesn't happen right away. A freshly imaged machine, log on, set your preference, log off, log back on, and you're good. Log off, wait 10-15 mins, log back on, and it's reset, and any subsequent logins reset it too (you can see it in the shell event logs where it's resetting). This is leading me to believe that SCCM is doing some kind of configuration to the machines post deployment. If I create a machine using the .wim from the Windows disk, and install Chrome during OSD, same results as above. If I create a machine manually, without SCCM, install Chrome manually, this actually works as expected, and no resets are seen. I've installed a machine with SCCM, then removed the client from it, still does the same thing, so it looks like something is being enforced during the OSD itself. If I take the machine out of the OU's with the group policy's, it still resets (regardless of whether a Domain Admin or Domain User logs on, it will reset that users preferences. I'm at the point where I need to call M$ to see what's going on, and see if they can work it out, but I thought I'd try here first! Just to add, I've also tried Windows 10 Pro 1903 as well, and it has the same result :(. Banging my head against a wall here :(. I have no GPO's enforcing default Apps (with or without the XML settings we're now forced to use). There is nothing on SCCM showing as it would cause this... Any help would be appreciated. Thanks Phil
  21. Hi, I have to deploy windows updates on critical servers which gets patched very rarely due to some team dependency. I have SCCM CB 1706 installed. My client set below conditions: 1. Updates should get downloaded beforehand 48 hours actual Installation date. 2. If needed, installation time may change. Deployment should accomodate that. 3. Deployment time is 2 hours for 1 batch. So in case if deployment gets carried over 2 hours, second batch should not start. How to achieve this 1. Without maintenance window 2. With maintenance window 3. Any other way apart from above 2 options
  22. Thanks for the great series. But I have wound up being not able to install agents on clients. This is probably because clients can't access \\CM01\SMS_MPL\Client. (MPL being my sitecode). Can you recommend a document describing required permissions for this environment. I assume I simply need to drop my users group into a local group on CM01 but some experimenting has brought no joy yet and I am loath to do anything with permissions I can't immediately back out of.
  23. awesome ! glad to see you using the SCCM labs and smoothwall too
  24. Yay! Adding Legacy NICs solved the problems it seems. I have powered off and restarted VM two times and no NIC config prompt appeared. Thanks a ton!:)
  25. you need to use legacy nic's for smoothwall, at least that's what i use
  1. Load more activity
  • Newsletter

    Want to keep up to date with all our latest news and information?

    Sign Up
×
×
  • Create New...