In yesterday’s post I described how you could extract Office 2003 updates. When they are extracted however, they still need to be slipstreamed into the package. I also created this script to automate the slipstreaming.
Basically for each extracted patch (.msp) file, it runs msiexec with the correct parameters. So if you have other msi packages that need multiple patch (.msp) files applied to it, you could use this script as a foundation as well.
Tags: automation, extract, msi, msieexec, msp, Office 2003, patch, patch file, Powershell, Script, Scripting, slipstream
Not so long ago I had to create a new Office 2003 Administrative Installation Point.
There were 2 choices:
- Use the default ISO and have WSUS handle patching after each install.
- Slipstream all available patches in the Office 2003 Administrative Installation Point.
Ofcourse option 2 is the best choice, because then the package will be the most secure from the moment the software is deployed. Also it saves bandwidth and time.
To slipstream updates into Office 2003, there are basically 4 steps:
- Extract the original Office 2003 files.
- Download the updates you want to slipstream.
- Extract the updates you want to slipstream.
- Slipstream the updates into the extracted Office 2003 files.
You can imagine that the older the source files are, the more updates there are to be slipstreamed. So it is best to use an ISO/CD of Office 2003 with the latest Service Pack.
Still if you have the latest Service Pack, you need to slipstream more than 20 updates. I personally don’t like these kind of manual tasks, so I created this script to do the extraction of the updates for me.
Ofcourse this script can be used to extract other kinds of updates as well..
Tags: automation, extract, Office 2003, Powershell, Script, Scripting, slipstream
In yesterday’s post I showed some commands to protect all or specific Active Directory objects from accidental deletion.
In some situations (by example preparing for a change) you might want to know which objects are protected from accidental deletion and which are not. Also when multiple people make changes in an Active Directory it might prove difficult to keep track of the changes.
To determine the protection status of AD objects, I use a script that checks the ACL of the AD Object. When Everyone is explicitly Denied access, it is protected from accidental deletion.
Tags: Active Directory, AD, automation, Microsoft, Powershell, protect from accidental deletion, protected from accidental deletion, Script, Scripting, Windows, Windows Server, Windows Server 2008, Windows Server 2012
In a previous blog post I explained how to enable the Active Directory Recycle Bin which allows you to restore deleted active directory object.
But even though it’s great to be able to restore objects, it is even better to prevent accidental deletion. What accidental deletion basically does, is modify the permissions on an AD object to Deny Everyone so you won’t be able to delete it by accident.
More information about protection from accidental deletion can be found in “Preventing Unwanted/Accidental deletions and Restore deleted objects in Active Directory” and “Windows Server 2008 Protection from Accidental Deletion“.
In Windows Server 2012 with all the new cmdlets, it has become much easier to enable protection from accidental deletion.
By example, you could use these commands:
#Get-ADobject class names
get-adobject -filter * | select objectclass | group objectclass
#Protect specific AD object classes from accidental deletion
get-adobject -filter * | where{($_.ObjectClass -eq “container”) -or ($_.ObjectClass -eq “organizationalunit”) -or ($_.ObjectClass -eq “user”) -or ($_.ObjectClass -eq “group”) -or ($_.ObjectClass -eq “computer”)} | Set-ADObject -ProtectedFromAccidentalDeletion $true
#Protect all AD organizational units from accidental deletion
Get-ADOrganizationalUnit -filter * | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true
#Protect all AD objects from accidental deletion
Get-ADobject -filter * | Set-ADObject -ProtectedFromAccidentalDeletion $true
Tags: accidental deletion, Active Directory, AD, automation, Microsoft, Powershell, protect from accidental deletion, protection from accidental deletion, Script, Scripting, Windows, Windows Server, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012
[EDIT] 09-04-2013 : As described in my blog post, this script has become unnecessary for most people. This is because Microsoft to allow almost every Flash site by default. [EDIT]
[EDIT] 13-01-2013 : Apparently for Windows RT, the script doesn’t seem to be working yet. Unfortunately I have no Windows RT to troubleshoot and resolve the issue. [EDIT]
Windows 8 and Windows RT include support for Flash in Internet Explorer 10.
In Windows 8 there are however two version of Internet Explorer 10 that handle flash websites differently. First there’s Internet Explorer 10 Desktop, which is similar as the Internet Explorer you’ve been used to with previous versions of Windows. Then there’s also Internet Explorer 10 (non Desktop), which is the Internet Explorer in the new modern/Windows interface (Metro) that is full screen.
Internet Explorer 10 Desktop allows Flash for all websites. Internet Explorer 10 (Metro) only allows Flash for websites that have been whitelisted.
Especially for Windows tablets, Flash support can be a selling point because most other tablets don’t have Flash support. It is however confusing for regular consumers that not all their websites will work. By example a friend of mine who’s a hairdresser, uses http://www.kapperssite.nl to show her customers hair models and their haircuts. The site is however completely in Flash and that it is not working by default is very annoying.
The websites that have been whitelisted are defined in your local appdate folder. By example: “C:\Users\Bjorn\AppData\Local\Microsoft\Internet Explorer\IECompatData\iecompatdata.xml”. This file also contains information about websites and which compatibility mode should be used for each. The segment between <flash> and </flash> contains the websites that have been whitelisted for flash. You can manually modify this file as described here: http://forum.xda-developers.com/showthread.php?t=1961793
Basic steps include:
- Modifying the iecompatdata.xml to add the websites you want to whitelist for Flash. Wildcards don’t work unfortunately.
- Open Internet Explorer 10 Desktop, press ALT, Tools, “Compatibility View setting”. Then Disable “Download updated compatibility lists from Microsoft”. This way Microsoft won’t overwrite the updates you’ve made in step 1.
- Delete the IE10 browser history. The disadvantage of this method however is, that you won’t be taking advantage of future compatibility updates because you’ve disabled the update functionality. Leaving it enabled however means that you you would have to keep re-adding sites you want to whitelist for Flash.
As a workaround, I’ve created this script that will automatically perform these tasks:
- Disable “Download updated compatibility lists from Microsoft”
- Close all internet explorer processes.
- Download the latest iecompatdata.xml to the appropriate folder. Currently the latest version is: https://iecvlist.microsoft.com/ie10/201206/iecompatviewlist.xml
The script however will dynamically look for the latest versions by modifying the date in the url.
- Combine the data from the latest iecompatdata.xml with websites you want to whitelist for Flash (specified in “C:\Users\Bjorn\AppData\Local\Microsoft\Internet Explorer\IECompatData\flashsitestoadd.txt).
- Backup the original iecompatdata.xml and store the modified iecompatdata.xml
- Clear the Internet Explorer browsing history.
Because automatic downloading of updated compatibility lists has been disabled, I advise to schedule the script to run on a regular basis (by example monthly). For instructions read this blog post: http://blogs.technet.com/b/heyscriptingguy/archive/2012/08/11/weekend-scripter-use-the-windows-task-scheduler-to-run-a-windows-powershell-script.aspx Keep in mind that this will clear your Internet Explorer browsing history though.
Tags: automation, Compatibility list, Flash, Internet Explorer, Internet Explorer 10, Powershell, Script, Scripting, Whitelist, Windows, Windows 8, Windows RT
Many companies and people in the past have encountered where they lost users, groups or other resources from Active Directory either by disaster or human error. Since Windows Server 2008 R2, you can use the Active Directory Recycle Bin to easily recover from this.
The AD Recycle Bin features requires a forest functional level of Server 2008 R2 or higher and is disabled by default. Also, once it has been enabled it cannot be disabled.
With Windows Server 2008 R2 you could only enable the AD Recycle Bin using Windows PowerShell and you could also only restore objects using CLI. With Windows Server 2012 you can both enable and restore very easily from the GUI using Active Directory Administrative Center (ADAC).
The script can be found here.
The script basically performs the following steps:
- Determine the current forest.
- Use parts of the current forest name to dynamically generate a command that is appropriate for every environment to enable the Active Directory Recycle Bin Feature.
- If the Active Directory Recycle Bin Feature hasn’t been enabled yet, enable it.
Even though it has become very easy to do using the GUI in Windows Server 2012, automating is Always better. Therefore I also added it to the script I used in: Home LAB Setup guide – 04 Configuring Server 2012 VM as DC with DNS and DHCP using PowerShell
Tags: Active Directory, active directory recycle bin, AD, AD Recycle Bin, automation, Powershell, recycle bin, Script, Scripting, Windows
In the first part of this LAB setup guide, I described the hardware selection process.
In the second part, I described the hypervisor selection and installation.
In the third part, I described VM guest considerations and preparations.
In the fourth part, I described Configuring Server 2012 VM as DC with DNS and DHCP using PowerShell
In the fifth part, I described easily creating (many) proper AD users with PowerShell
In this post I will describe creating a local PowerShell v3 Help Repository.
First of all, let me explain what a local PowerShell v3 Help Repository is and why you might want it. With PowerShell v3 not all help files are included. You can however always selectively download the latest versions of the help files (for specific commands). This saves space and also makes for a more flexible system where help files can be updated more easily.
Downloading the updates to the help files requires an internet connection however, and this might not be possible or desirable in many situations. Also if every server would download these files from the internet, this would waste internet bandwidth. Microsoft realizes this and provides you with the option to create a local PowerShell v3 Help Repository.
My script to create this local PowerShell v3 Help Repository can be found here. The basic steps include:
- Create a folder where the Help files will be stored.
- Share the folder.
- Create a scheduled task to daily update the help files in .the share
- Create a file in the share that contains the command that needs to be run from another server to update its help files using the local repository (so you don’t have to remember the command).
As stated in step 4, you can manually update the help files. Personally I prefer creating a GPO that creates a scheduled task on every other system to update the help files on a regular basis using the local repository share you just made. This way when you need the help files, you don’t have to wait until the update has been completed and you also don’t have to rely on internet access.
Personally I would have preferred it if Microsoft also offered an option to deploy the help file updates using WSUS. But for now, this will have to do.
Tags: account, automate, help, help files, Help Repository, ICT, lab, Powershell, Powershell 3.0, Powershell v3, scheduled task, Script, share, update, update help files, Update-help
In the first part of this LAB setup guide, I described the hardware selection process.
In the second part, I described the hypervisor selection and installation.
In the third part, I described VM guest considerations and preparations.
In the fourth part, I described Configuring Server 2012 VM as DC with DNS and DHCP using PowerShell
In this post I want to share with you this great blog post “How to use PowerShell to populate Active Directory with plenty enough users for SharePoint” by Wictor Wilén – SharePoint MCA, MCM and MVP.
What you basically do is:
- Use http://www.fakenamegenerator.com to create x number of users from countries you specify and containing fields/data that you specify. This will be sent by mail for free as a .csv
- Use PowerShell to import the CSV and create the user accounts in AD.
What I like about the method is that besides creating many users, it also uses user data that you could encounter in real-life. Also you can modify the user data to more closely match your desired environment. By example by specifying that you want to have Dutch and US names only. For testing purposes, it can be good to include names with strange characters as well, because when these work well …. chances are that everything works well.
[UPDATE 25-01-2014]
Since there were some issues with the original source, I decided to store a cached version as PDF as well (just in case) : How to use PowerShell to populate Active Directory with plenty enough users for SharePoint
It is best to visit the original site though, if it’s available.
[UPDATE 25-01-2014]
[UPDATE 24-03-2016]
An alternative method is displayed here: https://gallery.technet.microsoft.com/scriptcenter/Create-Real-Fake-Names-e1635ef4
[UPDATE 24-03-2016]
Tags: account, Active Directory, Active Directory Domain Services, AD DS, automate, DC, Domain Controller, fake name generator, ICT, lab, name generator, Powershell, Script, user, user data
In the first part of this LAB setup guide, I described the hardware selection process.
In the second part, I described the hypervisor selection and installation.
In the third part, I described VM guest considerations and preparations.
In this post I cover quickly configuring a Server 2012 VM as DC with DNS and DHCP by using PowerShell.
The steps I do take less than 10 minutes in my test lab now. Here’s a short description:
- Create a VM that uses your previously made parent disk.
- Configure the server name and IP addressing and reboot the computer.
- Install AD DS (domain controller) including DNS forward lookup zone and reboot the computer.
- Configure AD and DNS : Enable AD Recycle Bin, Add DNS forwarder, add DNS reverse lookup zone, create DNS PTR record for DC.
- Install + configure DHCP : Install DHCP, Add scope, configure scope, authorize DHCP server in AD.
The scripts I’ve created for steps 2 to 5 can be found here and are based on the great work Stefan Stranger already did in his blog post Installing a new OpsMgr 2012 (SP1) environment the fast way. I added some stuff of my own so it would meet my needs and I tried to keep it as generic as possible so other people can re-use my code as well.
PS: In step 2, IP addressing is not in place yet. To get scripts tot the system, consider:
- Putting the scripts in an ISO file that you can mount.
- Opening Hyper-V Virtual Machine Connection to VM and using “Clipboard”, “Type Clipboard Text”.
Tags: Active Directory, Active Directory Domain Services, AD DS, automate, configuration, DC, DHCP, DNS, Domain Controller, Domain Naming System, Dynamic Host Configuration Protocol, forward lookup zone, forwarder, Hyper-V, hypervisor, ICT, installation, lab, Powershell, reverse lookup zone, Script, Virtual Machine, virtualization, VM
I created this script to automate extracting English only MSP files from CAB files in the SCOM 2012 Update Rollup 3 (UR3) files. By default it will delete extracted non-English versions. With some minor modifications it can be used for any CAB file though, not just SCOM 2012 Update Rollup 3. It includes a lot of comments, so it is manageable and can be used for getting to know PowerShell better.
SCOM 2012 Update Rollup 3 can be downloaded here : http://catalog.update.microsoft.com/v7/site/search.aspx?q=2750631
The issue with SCOM 2012 Update Rollup 3 is that after downloading you’ll end up with a total of 41 CAB files. The large number of files is because they are for different components and in multiple languages. And what is even worse, is that the file names do not show which file is for which language.This script will extract all cab files to a subfolder and will then removes the non English ones. Below are some of the example files in Update Rollup 3 to give you an idea about the nondescriptive file names:
- all-kb2750631-amd64-console_1af57997fba722cdd3dfe4b2ddb4b8d8d829dd6f.cab
- all-kb2750631-amd64-console_3d61c9e090622b2b59ee8bf7b13b922e815bdf15.cab
- all-kb2750631-amd64-console_494a77ddaa09206f8f61ecdfb2edfcd1e82a497c.cab
- all-kb2750631-amd64-console_69bb307dbd450cfd8b732c2ac3845c9870bdc6d0.cab
- all-kb2750631-amd64-console_71c65fc2ded6769edbf610958780b5a8ac374f8c.cab
Deploying SCOM 2012 components and updates to them can be done in multiple ways: http://technet.microsoft.com/en-us/library/hh551142.aspx
Most of the work while updating will probably be updating the agents. Basically for SCOM 2012 there are 2 major ways to install agents:
- Push installation (initiated from SCOM 2012). Updates can then also be deployed from within SCOM (Remotely Manageable = Yes). Push installation is often preferred, because it is easy and also allows you to push updates to clients from within SCOM 2012. The downside however is that it also requires a lot of open ports (including RPC) which might not always be acceptable: http://support.microsoft.com/kb/2566152. Push install and update install can also consume a lot of bandwidth and depending on your architecture (b.e. WAN links), the push install might not be the best way.
- A manual installation (anything that is not a push installation). Updates cannot be deployed from within SCOM (Remotely Manageable = No). Manual installation includes running setup manually, using a GPO software install or using deployment tools like System Center Configuration Manager). Using the GUI, you cannot simply set an agent back to remotely manageable = Yes. You can change this in SQL though, but keep in mind that connectivity requirements still need to be met.
With Update Rollup 3, it is now possible to leverage WSUS / Microsoft Update to deploy updates (not the inital agent) to all SCOM 2012 components. I predict this will probably become the preferred way of updating SCOM 2012 for most companies:
+ It does not require many ports on your firewall to be opened.
+ Better bandwidth management (local WSUS, BranchCache, BITS).
+ Auto detects components on systems (component updates are not forgotten).
+ Still in control of when which updates are deployed/approved.
+ Leverage existing patch/update management procedures and systems WSUS/SCCM (standardization).
– Initial agent installation cannot be performed using WSUS.
PS: Also check these great blog posts when deploying Update Rollup 3:
Tags: Background Intelligent Transfer Service, BITS, BranchCache, CAB, cab files, decompress, extract, ICT, manual install, Microsoft, Microsoft System Center Operations Manager 2012, Microsoft Update, operations management, operations manager, Operations Manager 2012, OpsMgr, OpsMgr 2012, OpsMgr 2012 Update Rollup 3, OpsMgr2012, Patch Management, Powershell, push install, Remotely Manageable, rollup, SCCM, SCOM, SCOM 2012, SCOM 2012 Update Rollup 3, SCOM2012, service pack, System Center, System Center Configuration Manager, System Center Operations Manager, System Center Operations Manager 2012, testing environment, Update Management, update rollup, Update Rollup 3, WSUS
blog.bjornhouben.com 