Posts Tagged ‘Script’

Credit goes to J v D on the myITforum Configuration Manager email list for his response to my question about how to resolve this. I have adapted elements of his solution to suit my own situation.

Lately I’ve been doing a lot of Windows 10 1607 deployments some of which have been in-place upgrades from Windows 7 and Windows 10 1511.

I noticed that my multi-language settings were not being migrated as part of this process.

BEFORE AN IN-PLACE UPGRADE

2017-03-17_154018

AFTER AN IN-PLACE UPGRADE

2017-03-17_155042.jpg

So how do you resolve this issue? Well I’ve finally found a suitable and reliable way of setting these values as part of a Configuration Manager in-place upgrade Task Sequence.

Some background on why this problem has occurred.

For Windows 10, I like others have used the English (US) ISO.  I’ve then added the en-GB language pack for English (Australian) language support as part of a Configuration Manager Task Sequence. For Windows 7 we have always used the media with English (US) as the base system language.

This is important to note as you can’t in-place upgrade an existing OS using Windows 10 media from another base system language i.e. you wouldn’t be able to in-place upgrade a Windows 7 OS using a base system language of en-US with say the Windows 10 en-GB media.

The combination of this multi-language environment has resulted in the subsequent Windows 10 1607 language settings not being correctly configured for the welcome screen or for new user accounts following in-place upgrades.

THE SOLUTION

1. Add a  Run Command Line step in your in-place upgrade Task Sequence that references your language package. This adds the relevant Language Pack and Feature on Demand cab files. This is the same process that you would undertake if you were preparing a reference image. As an example you could use a cmd file that contains the following (adjust for your language):

2017-03-17_191509

2017-03-17_161559

2. Create the following SetLanguage.xml file and adjust as per your requirements. This xml file is imported as part of a scheduled task that gets created later in the sequence. I would recommend using Notepad++ to error check the file and then test it by manually running the import command in step 3. This way you can be confident that it is working before moving to testing with in-place upgrades.

2017-03-17_161944

3. Create the following PostUpgrade.cmd file. This cmd file is run as part of a step in the task sequence.

2017-03-17_162245.jpg

4. Create a new package in Configuration Manger containing these 2 script files and call it something appropriate.

2017-03-17_164657

5. Modify your existing in-place upgrade Task Sequence to include the following 3 steps.

2017-03-17_162936

SMTSPostAction with a value of cmd /c shutdown /r /t 0 /f

2017-03-17_163111.jpg

Command line of xcopy * “c:\Windows\Temp” /D /E /C /I /Q /H /R /Y /S

2017-03-17_163213

Command line of: schtasks /create /tn “PostUpgradeTask” /tr “c:\Windows\Temp\PostUpgrade.cmd” /RU SYSTEM /SC onstart

These sequence steps copy the script files to c:\Windows\Temp, then create a scheduled task. Finally the SMTSPostAction restarts the PC after the sequence has finished running so that the scheduled task executes and runs PostUpgrade.cmd. This cmd is responsible for importing the adjusted language settings.

There you have it, once implemented you should have a working solution and your language settings should match what was set in the previous version of Windows 10.

Cheers

Damon

 

 

Advertisements

I’ve implemented this solution based on information provided in the following blogs – credit to these people for posting this information.

http://www.deploymentresearch.com/Research/tabid/62/EntryId/97/PowerShell-wrapper-for-MDT-2012-Update-1-and-MDT-2013-Preview.aspx

http://blogs.technet.com/b/deploymentguys/archive/2013/10/21/removing-windows-8-1-built-in-applications.aspx

So I’ve moved on from my old process of corporate WIM image creation. I used to build up an image from a source ISO for a respective operating system using Hyper V, make my customisations, apply patches, then use MDT to do a sysprep and capture. I know, I know, there are probably numerous reasons why you shouldn’t do this. Well no more after watching Johan’s session from System Center Universe this year here 

The new process involves the more contemporary approach of doing a completely automated build and capture in one process with MDT performing any additional changes using scripts and additional steps. The session that Johan presented is in my view the best by far that I have seen.

One thing that wasn’t covered was how to remove the built in Windows 8.1 Modern Applications. In my case (like many others) we are deploying Windows 8.1 and do not wish to have all of these applications available.

Here is a solution you can implement which will remove these apps as part of your MDT or Configuration Manager Task Sequence. My example will be in MDT 2013.

Firstly create a new powershell script from the this blog, you can amend the script as required so that it only removes the applications that you want. Alternatively I have copied the script syntax into a word document here removemodernappsnew – please make sure that you edit this script in Powershell ISE to confirm that there are no syntax errors.

Copy the script to your MDT server sources folder.

Create a new MDT application and give it an appropriate name such as Remove Windows 8.1 Modern Applications

RemoveApps1

Use the following powershell wrapper command – credit to Johan who posted the install wrapper argument here

powershell.exe -Command “set-ExecutionPolicy Unrestricted -Force; cpi ‘%DEPLOYROOT%\Applications\Remove Windows 8.1 Modern Applications\RemoveWindows8Apps.ps1’ -destination c:\; c:\RemoveWindows8Apps.ps1; ri c:\*.ps1 -Force; set-ExecutionPolicy Restricted -Force”

Note you will need to adjust the path to your powershell script depending on how you setup the application in MDT.

RemoveApps3

Now just add an install application step in your existing MDT / Configuration Manager Task Sequence, its that easy.

RemoveApps2

If you implement a Suspend action in your MDT Task Sequence you can check that the apps have been removed.

RemoveApps4

RemoveApps5

Cheers

Damon

Last year I attended a Server 2012 course with a few of my work colleagues and there was a tiny section on creating Active Directory accounts with PowerShell. This was demonstrated using the Active Directory PowerShell Module and the New-ADUser command with a csv. The basic premise was that you had a csv file with all the account details which the script read, creating the AD accounts.

This is great for a scenario where you have to create a lot of AD account all at once, but what about the on-going process of creatingnew AD accounts as users start with an organisation?

We had quite an arduous manual process to follow so I’ve expanded on that demo in the training lab to produce a script that suits our requirements and automates everything. The script does the following:

  1. Checks for the presence of the Active Directory module and imports it if required.
  2. Sets the Organisation Unit for the AD account to be created in.
  3.  Sets the variables that are needed to create the account such as username, first name, last name, password etc. There is a built in check to make sure that the username isn’t already in use. The script also sets     variables for a few attributes that we are using for exchange mailbox and billing purposes.
  4. Creates the AD account.
  5. Adds specified AD groups to the account.
  6. Prompts if additional services are required like an Exchange mailbox or Lync account.
  7. Creates the users home directory and then sets permissions. We have fairly specific home directory paths and share names so you will most likely need to play with this and alter to your requirements.

The part of the script that actually creates the account is quite small

New-ADUser -Name $dplname -SamAccountName $samname -DisplayName $dplname `
-givenname $givname -surname $surname -userprincipalname $upname -emailaddress $email `
-Path $targetou -Enabled $true -ChangePasswordAtLogon $true -Department $department `
-OtherAttributes @{‘departmentNumber’=”$departmentnumber”} -HomeDrive “M” -HomeDirectory $homedir `
-Description $description -Office $office -ScriptPath $loginscript -AccountPassword $password `

I have used some snippets of code from Source Forge and few other sites, credit to those that posted these sections, in particular, the PowerShell script to set share permissions on a folder.

The script has been saved as a word document to allow it to be uploaded. Just copy the text into a text file and rename it to a the ps1 file format.

USE THIS SCRIPT AT YOUR OWN RISK, this script should be altered as needed and fully tested in your lab environment before any use in a production environment.

CreateADUSer

2014-02-11_102758

2014-02-11_103728

2014-02-11_103826

2014-02-11_103942

2014-02-11_104126

2014-02-11_104258

2014-02-11_104415

2014-02-11_104549

Cheers

Damon

So recently I discovered that certain file extensions with my Windows 8 Enterprise deployments were associated by default with the new modern/metro applications. These included .jpg .bmp etc. Now for tablet users this may not pose a problem but for a Desktop Enterprise scenario it certainly raised some eyebrows with my end users who were consistently switching between the traditional desktop applications and the new modern applications when working.

To combat this change Microsoft have introduced a new way to set and manage these file type associations. You can no longer use a VB or Batch file to script these changes in the registry due to a security hash checking process built into Windows 8. We can now use the Dism utility to generate an XML answer file which we can then deploy and manage using Group Policy.

I recommend following these steps to configure and deploy your desired associations.

1. Deploy a copy of your current Windows 8 Enterprise WIM with your chosen deployment solution. Run up Default Programs under Control Panel and look at your current file type associations. Take note of which ones you want to alter and make your changes

.Image

2. Now we need to generate our XML file. Run an elevated command prompt and type Dism /Online /Export-DefaultAppAssociations:\\youshare\AppAssoc.xml This will output a file with all of your file types and their current associations.

Image

3. Edit this file to include only the file associations that you wish to change. You can elect to keep the file intact in its entirety if you wish. Optionally you may wish to make copies of the file if you have different file association requirements for different business groups in your organisation which you can target using separate Group Policies.

Image

4. Once you have this XML configured to your preference we can specify it in our Windows 8 Group Policy setting. Open up the Group Policy MMC on your Windows 8 environment (with RSAT installed) or Server 2012 instance and locate the policy Computer Configuration\Administrative Templates\Windows Components\File Explorer\Set a default associations configuration file Now specify the location of where you have stored the XML file. A possible option is to use a network share, or you may want to copy/inject the file locally to the Windows 8 Enterprise build as part of a Configuration Manager Task Sequence.

Image

Image

Hey presto! You now have a method of controlling and setting file associations in your organisation which is flexible enough to cater for the different scenarios you may find yourself having to manage – thanks to the Modern Desktop 🙂

Technet Reference http://technet.microsoft.com/en-us/library/hh825038.aspx