epoch71

Delete me!

Ok so I removed the language pack from the CS.INI. So after applying the WIM I'm not prompted to choose a language, meaning Windows will be en-US which is not what I want. It's still firing up OOBE though, which is not what I want. This doesn't happen on my Windows 7 reference image, and the config pass settings are the same.

I'll amend the cs.ini and create an image and report back in a few hours!

Hi Rens, thanks for the reply. I cannot disclose the reasons for LTSB other than to say it's a definite operational requirement. The ISO was downloaded from VLSC. Regarding the unattend, all the settings you specify are present, with the exception of NetworkLocation, which is deprecated.

Hi I'm creating our first Windows 10 reference image. This is for a small trial deployment in our virtual infrastructure. We're using 1607 LTSB. The WIM is created in MDT 2013. However, I'm experiencing an issue. After applying the sysprepped WIM to a blank VM it's firing up an OOBE sequence, starting with asking whether I want English US or GB (I want GB ... the en-GB language pack is added during MDT, specified by GUID in the customsettings.ini). Once the WIM is applied I need to perform some VM specific customisation and optimisation. So all I want is for the machine to start up and log in with the Administrator account. I don't want to go through an OOBE, choose a language, create a user etc. None of that - just log in so I can prepare the VM template. Clearly I'm going wrong somewhere, in one of the config files (unattend.xml and customsettings.ini attached, with some redactions). Any help will be gratefully received! customsettings.ini unattend.xml

Got it .. thanks!

Thank you for your advice. Much appreciated.

Hi Rens Thanks for replying. So I can see in the MDT task sequence that LTISysprep.wsf executes prior to the image capture. And I see there's some rearm sections in there for Office 2010 - 2016. I guess that means we're all good then?

Hi all Currently in our Windows 7 reference image (created in MDT) we perform an Office 2010 cache-only install. Then, during the SCCM OSD task sequence we do an Office 2010 install from the cache. The downside we're finding with this is that Windows patches are installed when the reference image is created, but not Office patches. So, when a machine is built and hits the user's desk they may very well have a fully patched copy of Windows, but a load of Office patches will be waiting. So my question is are there likely to be any problems with Office 2010 being fully installed in the reference image? Or might we encounter issues (GUIDs .. SIDs ... whatever)? For sure the image will be slightly bigger, and take a little more time to deploy, but if it means less post-deployment hassle for our users then I'm happy with that. Thanks in advance for any advice.

Hi all I have a case open with Microsoft regarding a distribution point issue, and I need to get hold of the Content Library Explorer from the Configmgr 2012 SP1 toolkit. Unfortunately that toolkit has now been retired. Only the original RTM and the R2 toolkits are available. I don't suppose anyone here has a copy of the SP1 toolkit that they could make available to me? Thanks in advance for any help! (Also posted at myitforum.com)

Hi there. It's 2012 SP1 CU2. I have a bit more info. I think this is a policy/MP issue. If we deploy the task sequence and then take a machine offline soon after, the job will run successfully from Software Center. However, if a machine is offline for a 'length of time' then it fails to run as described in my first post. I suspect the length of time is the machine policy retrieval interval (1hr). I've had a look at the execmgr and locationservices logs and I can see it successfully speaking to a MP when the job works, and failing to contact a MP when it doesn't. Could this mean that a cached deployment will not work offline outside of the machine policy window? If so, this is not the behaviour I was expecting!

Hi all We have a task sequence that performs some tasks for a migration of our RAS product (from one vendor to another). Basically, it installs the new product and then uninstalls the old one. The deployment is set to 'required' with a scheduled run date far in the future (1st August 2016), and is also set to "allow user to run outside of assignments". This allows us to cache the job, and then at the appropriate time we'll modify the deployment schedule to 'run now'. Connected users will receive the update to the deployment and the TS will begin. Remote users, who will not be able to connect using the old deployment our go-live date can launch the cached deployment from Software Center. This has all been tested time and again and has worked without issues. Until our dry-run testing today! If I try to manually start the job from Software Center on a machine that is offline, the entry in Software Center says 'installing' for about a minute, then it stops and reverts back to displaying the scheduled run time. I've checked the cache and can confirm all the content is there. If I subsequently connect this machine to the network, and try to run it again, it does so immediately (and I see no changes to the cache so I'm confident there was no missing content). Likewise, if I remove the machine from the deployment collection, update policy on the machine to observe the Software Center entry disappear, then delete the cache I can re-add the machine to the collection, watch the content cache, and then disconnect from the network and successfully run the job. (sorry for the long sentence!) I'm really at a loss to understand why these cached, offline installs are not working. Again - this was all tested without issues leading up to this critical testing day! Any advice on why these deployments are not running would be greatly appreciated. Thanks in advance. (Note: I felt compelled to cross-post this on a couple of support forums).

Yeah I prefer using 'version' for Lenovo too - it makes the query more readable (and shorter). For Dell and HP we use 'model', which similarly is more human readable. No idea why Lenovo (or was it IBM) decided to make 'model' so cryptic ...

Hi all We have a requirement to execute a task sequence on our clients (deletes various files, registry entries etc). We need to schedule the TS to run within a specific 2 week window. However, if clients are connected via VPN when the execution window opens, the TS must not run. When the client subsequently reconnects to the corporate LAN, then the we need TS to run. How can I acheive this? I've taken a look at global conditions, using Win32_NetworkAdapterConiguration.IPAddress to identify if the client is in the VPN IP range, but I can't figure out how to use them as a TS requirement (there are no application installs in the TS). Thanks in advance for any advice.

Hi all I noticed recently that I'm not getting any hardware inventory from a selection of machines. Specifically, all machines that are hosted on a VMware Horizon View platform at one of our locations. All physical devices (laptops/desktops), wherever they may be, are happily reporting in. Likewise, clients on another View platform at our main site are also reporting correctly. It's just the ones at this other View platform that are not submitting HW inventory. I noticed in the SMS_DISCOVERY_DATA_MANAGER logs that we're getting hundreds of messages like the following (all from machines on that View platform): Discovery Data Manager has processed a discovery data record (DDR) for computer "MACHINE_A" with the SMS identifier of "GUID:<GUID_A>" which has reported a new hardware identifier of "<HW ID>". 1 existing records sharing this hardware identifier have been marked as obsolete. The data in these records has been superseded by the data in the new record. Possible cause: The operating system and ConfigMgr client have been reinstalled on this computer. ---------------------------------------------------------------------------------------------------------------- Discovery Data Manager has processed a discovery data record (DDR) for computer "MACHINE_A" with the SMS identifier of "GUID:<GUID B>" which has reported a new hardware identifier of "<HW ID>". 1 existing records sharing this hardware identifier have been marked as obsolete. The data in these records has been superseded by the data in the new record. Possible cause: The operating system and ConfigMgr client have been reinstalled on this computer. ---------------------------------------------------------------------------------------------------------------- Discovery Data Manager has processed a discovery data record (DDR) for computer "MACHINE_A" with the SMS identifier of "GUID:<GUID C>" which has reported a new hardware identifier of "<HW ID>". 1 existing records sharing this hardware identifier have been marked as obsolete. The data in these records has been superseded by the data in the new record. Possible cause: The operating system and ConfigMgr client have been reinstalled on this computer. ---------------------------------------------------------------------------------------------------------------- In each case, the GUID differs, but the hardware ID is always the same. I'm really at a loss to explain this. I'm not seeing this occuring on clients on our other View platform. I'm assured that the pool settings between both View platforms are identical, as are the images used to create the virtual machines. I'm not responsible for our View infrastructure, nor do I have much experience in it, but the onus is on me to prove this is NOT an SCCM issue!! So, any advice on what could be causing this issue would be gratefully received. Thanks in advance.