tregelen

Ok, I will see what I can work out with it and get back to you.

Kind of but I would call the Windows 7 image ultra-thick. The Windows 7 image is a single WIM that has x64 and x86 with a number of applications installed making the total size over 15GB. No matter what image you are wanting to deploy it has to download the entire WIM to only use half of it. Then after that it actually uninstalls a number of the applications that were installed in the WIM and installs updated versions via packages not the application model, hence increasing the deployment time. This is because for some reason whenever we service or try to recapture that WIM it breaks and you can no longer deploy Windows 7. It's in kind of a 'its being retired anyway, lets not waste time' thing as we only image maybe 1-2 machines a week with that OS. Windows 8.1 is a lot lighter, only having x64 and some applications coming in at 6GB Windows 10 (the one I created) being the thinnest of them all at 3GB which only has the OS, no applications. That then has the applications dynamically installed via a frontend form that I wrote so that it can be customised at time of imaging without having to recapture WIMs all the time. That is regularly serviced with OS patches through the SCCM console I did look into FOG and it looks interesting. I passed it along to a colleague who does PC repairs at his home and he is going to set it up for that (he uses MDT atm) so we will see what kind of speeds he gets from that.

That is interesting, it worked for me. Are you running it as 'Bypass' in the TS step? Are you able to F8 and do the steps manually? I was just able to do the commands in my VM and it worked fine. I will try it as a step instead of manually and see if I get the same result.

Where I am it depends on which OS is being deployed as we have gone through a number of different architects (basically each OS was done by someone else and never really looked at after that) and they all had different approaches. Windows 7 takes 90-100 minutes with all apps and updates Windows 8.1 takes 75-80 minutes with apps and updates Windows 10 takes 30-35 minutes all apps and updates We have all SSDs so no idea what it takes on SATA but 4 minutes is kinda crazy.

Try this $var = New-Object -ComObject Microsoft.SMS.TSEnvironment [regex]$pattern = "-" $var.Value("OSDComputerName") = ($pattern.replace($var.Value("OSDComputerName"), "", 1)).Replace("TW7", "TW10").Replace("LW7", "LW10")

We have over 200 X2's and they are all working fine however we don't PXE them. We attempted to get the PXE working but it all became too hard and in the end we decided to use USB-Ethernet adapters that have USB ports on them and boot to a USB. This was how we did the Surface Pro 3 and other devices that don't have built in Ethernet. Could you do the same? At least that way you would be able to get into WinPE and be able to do some diagnostics.

Thanks for the input guys. Unfortunately im not a high enough level to be involved with the meetings and negotiations but I have passed on what you have said to someone who is. I don't see this ending well...

So a little background regarding the question. I currently work for a government agency looking after ~2k PCs. The 'powers that be' are in the process of outsourcing the entire desktop (level 2) and SOE/SCCM work to a private company. At the end that will end up being ~60k PCs across 16 SCCM environments and 26 different domains (politics means there will be no consolidation). In the negotiations the vendor has said that they will not package anything below an install base of 10, as we dont have a minumum I just wanted to know if that number would be a normal number for that or if it was low/high. If it was too high I wanted to get in our standard as being lower before the negotiations are completed so we can say that our current limit is lower so they need to match that.

Anything like that I tend to use (and infact I use it for all my packaging) the PowerShell App Deploy Toolkit http://psappdeploytoolkit.com/ See how that goes.

Hey, I was just wondering if you guys have a minimum install count that you have to reach before you would package an application. Currently where I work there isn't a minimum, its basically however the person who replies to the job feels at the time. What I want to do is have a minimum so for example a job comes through for an application that will only be installed on two machines, that is a manual installation by the desktop support team but if the job has 5 installations then it's packaged and deployed through SCCM. Just wanting to know the thoughts of the wider community.

Ill do some tests in my environment and see what I can come up with.

That will work, or you could add in an additional .Replace on the same line. It technically wont skip that line, it will still run it it just doesnt find that string to replace. $var = New-Object -ComObject Microsoft.SMS.TSEnvironment $OSDComputerName = $var.Value("OSDComputerName") $var.Value("OSDComputerName") = ($OSDComputerName).Replace("TW7", "TW10").Replace("LW7", "LW10")

Did you set the maintenance window for the time you want it to reimage?

Have you checked to see if they have synced through to WSUS itself and just not appearing in SCCM?

I have experienced this issue before and asked a MS Premier Field Engineer and he told me it was a 'quirk'. I took that to mean he didn't know why. I tend to ignore the pie chart and use the detailed numbers.

Firstly you would need a way to get that information into the database before you could report on it. How you get that information depends entirely on the manufacturer and how they allow interaction with the BIOS. It is likely that you would need to write a script to get the status of the password, write that to the registry and have SCCM collect that key during its scans. You could then report on the status of that key. The script would need to re-run at regular intervals to ensure that the password wasn't removed. Your data would always be a little out e.g. not real time but it would give you a pretty good indication. As an aside some manufacturers do write BIOS information into WMI so if you had them you could leverage off of that.

Happy to help

It worked for me doing it during the task sequence. As YPCC said if you just run the script while in the OS then it wont work as the com object (Microsoft.SMS.TSEnvironment) wont be able to load. If you run it during the task sequence then it will work. And make sure you running it as a PowerShell script during the task sequence.

Have you tried 'Always rerun program' and have the schedule set to the time you want it? In theory it should always rerun the TS at that time each day (or every 3 months for Prod) An overly complicated way of doing it would be to write a script that creates a new deployment every 3 months and deletes the old one. This could be set as a scheduled task on the server.

You can use the PS App Deploy Toolkit to do this (http://psappdeploytoolkit.com/). It will not only kill the process but stop it from relaunching while the copy is happening. The only issue I can see is the relaunching of the application when its finished, I have never tried to do that personally but im sure it can be done. I would create this as an application instead of a package with the detection method being the new file, that way it will only run on machines that it needs to run on.

I use one TS for both. Use the variable '_SMSTSBootUEFI' to determine if the machine was booted UEFI or not and use those as your options.

I have started to do all of my packaging in the PS App Deploy Toolkit (http://psappdeploytoolkit.com/). It handles MSI and EXE and has really great logging options and error handling.

If Windows 7 capable of UEFI and Bitlocker? Personally I have never done it but I thought that it was too old to work with that and it wasn't supported until Windows 8. I'm happy to be proven wrong on this however.

I don't think I understand your question. Do you mean can do steps based on if it is UEFI or not? In that case, of course it can. Use the condition Task Sequence Variable '_SMSTSBootUEFI' equals 'True' and that will only run if you have booted to UEIF and 'False' if you have not. If that is not what you have asked, let me know and im sure we can work something out.

Oh with the windows logo. I have never changed that before but I think I read somewhere that is in a DLL and you would need to modify that. And someone correct me if i'm wrong but hacking DLLs makes your environment unsupported by MS and therefore you wouldn't be able to log any support calls.