How to create a Windows PE boot disk

Some time ago I worked a lot on this topic, and had a good system for creating Windows PE disk, but recently I had to adapt the workflow to changes in the WAIK (Windows Automated Installation Kit) introduced with Windows 7/2008 R2. I won’t go into details on what’s new, but as far as I am concerned it made the whole process quite a bit easier.

Maybe I should explain also what the rest of the Internet will probably tell you: “What is Windows PE?”

Answer: Windows PE is a lightweight version of the Windows operating system.

Why should you care about Win PE?

Answer: Well because you can…

-Access the NTFS shares, map drives and copy data over the network

-Format and partition disks and make bootable USB sticks

-Run admin tools like PsTools, NTPWEdit (password recovery)

-Run WMI and batch scripts to automate Windows 2003 Server / Xp installations

-Edit offline registry of a PC (e.g. change it’s IP address, start/stop services) when you can’t login to the OS for some reason.

It’s been around since Windows Xp (versions 1.x), but only since version 2.0 and now version 3.0 do have some real punch to them. In a way I think it is better than other Windows boot CD’s like Bart and the likes, because you can get MS support and it provides a “clean”,”supported” way to customize it over time with drivers and apps.

Here’s what we will do to get a working WinPE 3.0 boot image:

  1. Download WAIK and install it
  2. Copy files from the WAIK source folder.
  3. Mount the WIM image
  4. Add additional components to the WIM
  5. Integrate drivers into the image
  6. Add applications/other scripts/files to the image
  7. Unmount WIM Image
  8. Burn the image into an ISO file

WAIK Installation

In order to create this WinPE disk you need the WAIK (Windows Automated Installation Kit). This is for WinPE version 3, there are more versions of this WAIK out there, and this tutorial only works for WinPE 3.0.After you’ve downloaded it simply mount and install it. Should you have any issues with the installation (i have some trouble in the days of 2.x) check the contents of the ISO image there should be some file called “wAIKX86.msi” that you can use to launch the installation on a 32b OS, same goes for 64b OS. Installation is pretty simple, next next next.

Copy Required files

I should get this out of the way from the start. These steps are a scripted approach to make a boot disk. While I’m sure there is a GUI somewhere, while I was building my workflow using it was impractical, as I needed a way to reduce user errors and test quickly different approaches in an automated way.

To make this whole process easier make sure you add following paths to your %PATH% environment variable: %PROGRAMFILES%Windows AIK\Tools\PETools

Also create a folder where you have full administrator rights (in this post i use “e:\PE”). Save yourself some headache and use a shortname with no spaces. Needless to say you need to be an administrator on the computer you are using for this task and all of the commands need to be run from an elevated command prompt.

First step is to get ourselves all the files that we will need to make the image. These files are installed by the WAIK installer, and MS also conveniently provides a batch script that copies everything. From the elevated prompt run this:

start /wait cmd /c copype.cmd x86 e:\PE\winpe_x86

We use copype.cmd located under %PROGRAMFILES%Windows AIK\Tools\PETools. The script copies the x86 WinPE files to a customization directory.

Mount the WIM Image

Next we use DISM to mount the boot.wim image and begin servicing it. MS introduced this tool called DISM (Deployment Image Servicing and Management) as a single point of servicing the WinPE image.

c:
cd "%PROGRAMFILES%\windows aik\Tools\x86\Servicing"
Dism.exe /mount-wim /wimfile:"E:\PE\winpe_x86\winpe.wim" /index:1 /mountdir:"E:\PE\winpe_x86\mount"
::list packages installed - do not use quotes in image name
dism /image:E:\PE\winpe_x86\mount /Get-Packages

We mount the image (a .WIM file) to the “e:\PE\winpe_x86\mount” directory. Once we mount the image we can do anything with the files inside the mounted image. I also did a listing of the packages inside the image so you can see what’s inside it. We just have the basics, a language pack, and the foundation. When using dism with /image be careful to not use quotes in the image name.

Add WIM components

Now we can add so called packages to the WIM image. These packages are extra features you may want your image to have, like WMI support, MDAC support, Windows 7/Windows 2008 server setup screens, support for other languages, etc. For a list of the available package for the WinPE x86 version look in %PROGRAMFILES%Windows AIK\Tools\PETools\x86\WinPE_FPs.

c:
cd\
cd "%PROGRAMFILES%\windows aik\Tools\x86\Servicing"
::adding packages
Dism /image:e:\PE\winpe_x86\mount /Add-Package /PackagePath:"%programfiles%\Windows AIK\Tools\PETools\x86\<add-your-package-filename-here>"
::add here any other packages you need

For enabling vbs and WMI support add these packages: winpe-scripting.cab, winpe-wmi.cab, winpe-mdac.cab, winpe-hta.cab. I’ve added MDAC and HTA packages to the list in case your vbs scripting requires them, There are corresponding packages in the en-us folder, add them aswell, with the syntax above. This is how the output should look like once you run all commands for adding the packages:

In the end run dism /image:E:\PE\winpe_x86\mount /Get-Packages to list the packages you installed.

This covers half the process I described at the start of this post. in the coming days the second part of this tutorial will be finished. I hope you found it useful, have a great week!

Removing specific message(s) from multiple Exchange 2007 mailboxes

I seem to be doing quite a bit Powershell scripting these days, and some of related to MS Exchange 2007. One issue we had recently was that loose permissions on Distribution Lists with hundreds of users + too much spare time for some users generated a lot of unwanted message traffic. I don’t want to discuss prevention measures like restricting who can send emails to big DLs or using Microsoft AD RMS to restrict what can be done with emails. Our goal here is to clean up the mess ;).

Essentially you can get some info about the message and mailboxes, and use it with Export-mailbox to remove the data. That is how I initially found this link, but what is not written there is that you need to have all the prerequisites for running export-mailbox, and also running it on hundreds of mailboxes may take a while. I decided to do it my way,by building on what I found on that blog.

This is “Mass Remove message(s) from mailboxes – My Way”.Depending on your situation you can apply these steps multiple times:

  1. Identify the message that started it all
  2. Track the message on the Exchange Servers and compile a list of unique recipients of the message.
  3. Remove the message from the offended mailboxes (there may be special requirements to perform the task, see here)

Identify Message

Getting the information should be pretty easy, someone probably forwarded you the copy of the message(s) to be dealt with. You want to get this info as a minimum: subject,sender,date and time message(s) was/were sent. When you have enough info, open the Exchange Management Console > Tools > Message Tracking and from there identify which of the events represent the time the message originally arrived on the Transport Servers. For that event grab the “MessageID” Value. We will use this in the following steps to find all events relating to that specific messageID.

Track Message

Assuming the worst case scenario you have to do tracking across all Exchange Transport Servers, the speed of the process depends on how close to your Exchange Transport Role Servers you are running the tracking. I suggest you make sure this process runs in the same LAN as the Exchange, especially the export-mailbox part. Anyhow, to get all messages sent by “baduser@foo.com” across all transport servers in your Exchange run this:

$TrackingLogResults = get-transportserver | where {$_.Name -like "<optional filter>"} | foreach-object  {Get-MessageTrackingLog -EventId DELIVER -MessageID <MessageID from Step1> -ResultSize Unlimited -server $_}
  • Get-TransportServer gives you all the transport servers in the organization
  • Where clause filters the servers list, you can leave it out, it is helpful if your HUB transport servers are named in a specific way, and you know the message did not leave the organization, so you can exclude a search on the Edge Servers.
  • Foreach-Object cycles through all servers and performs the search
  • Get-MessageTrackingLog searches each transport server tracking log for DELIVER Events that correspond to messages with that specific MessageID. It returns unlimited results. The server that is being searched is piped from the Foreach cmdlet.
  • If you run the last cmdlet without the EventID filter, you will get lots of other EventID’s like fail,send,receive,routing,expand. You just need deliver, DELIVER is important because it basically says “OK, this message passed all of my checks I am now sending it to the Mailbox Server so it can submit it to the mailbox store”, so you get a list of just the actually affected mailboxes.

This may take a while to run. Once it is finished we have to get the list of people that the message was sent to. The easy answer would be “why not just do $TrackingLogsResults | select-object Recipients and pipe it along to something else?”

Well you can do that, but in some cases Recipients means actually a bunch of other addresses, and each recipient may appear multiple times in the entire list.

e.g. – this could be a list returned by the “easy” command

{john@foo.com}

{John@foo.com,Jane@foo.com}

{Jill@foo.com,Josh@foo.com,Jake@foo.com}

Having duplicates is inefficient, everything will take longer in next steps. What I wanted was to have a list without duplicates, plus I get to show you some more “nice” scripting stuff 😉

Compile Recipients List

I spent quite some time figuring this out, so someone out there better find it useful :). The next step involved a “google shovel” to “dig up” how to break up those objects into one big list. Then the plan was to have a list that just had the unique email addresses – ideally. So here’s the “magic”:

$RecipientsExpanded = @()
$RecipientsExpanded = $TrackingLogResults | foreach-object {$RecipientsExpanded  = $RecipientsExpanded  + ($_.Recipients)}
$RecipientsGrouped = $RecipientsExpanded | group-object
$UniqueRecipients = $RecipientsGrouped | select-object Name | sort-object -property name
  • We created a blank array object that will host all recipients addresses in “expanded form”.
  • For each result from the TrackingLog we added the array ($_.Recipients) to the $RecipientsExpanded array. At the end of this we have a single array with all the addresses, each an individual element in the array.
  • The Group-Object cmdlet is used to group all addresses by their name and in the end you have the list of unique email addresses.

Actually remove offending messages

Please see this link if you are planning to export the messages to PST. What is left to do is to take a page from the MSExchangeTeam blog and run get-mailbox| export-mailbox combo, only we are doing it on a reduced scale, only on the mailboxes that need it, that why I went through all the trouble of making that list!

$MailboxesList = $UniqueRecipients | foreach-object {
      $Filter = "PrimarySmtpAddress -eq '"+$_.Name+"'"
      get-mailbox -ignoredefaultscope -resultsize unlimited -Filter $Filter}

The code above handles this task for forests with child domains. I covered reasoning and use of –Ignoredefaultscope and –Filter in a previous post.

#get current admin UserPrincipalName
$Admin = [Security.Principal.WindowsIdentity]::GetCurrent().Name
#elevating the administrator's account to fulll access over all affected mailboxes
Add-MailboxPermission $MailboxesList -AccessRights FullAccess -User $Admin
export-Mailbox -Identity $MailboxesList –ContentKeywords <enter part of message body> -Recipients <add recipients list> –TargetMailbox admin_ –TargetFolder "RecoveredEmails" –DeleteContent
  • The final step grants the admin user full access over the mailbox. The account being granted that right is $Admin, the account under which the script is running, it contains the UserPrincipalName of that account.
  • You also need to have admin rights on the “TargetMailbox” and the “TargetFolder” should also exist beforehand.
  • We export the offending message(s) using Export-Mailbox. Here it is important to be very careful and make the filtering as strict as possible, since here you cannot remove a message based on the MessageID, so you could end up removing many more messages. Refer to the documentation for export-mailbox, for all available switches for this purpose.

After you run the last command get ready for some really long waiting, as it goes through all the mailboxes. Once it is finished, remove your permissions from those mailboxes.

Remove-MailboxPermission $MailboxesList -AccessRights FullAccess -User $Admin

Phew this was a long post, but validating everything I explained here, took a while. The post is also packed with bits and pieces that can be your building block for other Exchange Shell scripts. I tried to show you how to take Exchange TrackingLog data and build a list of unique recipient addresses that you can use to filter out an unwanted message you tracked in the logs, and do that using export-mailbox commandlet. If you have any feedback/corrections/omissions please feel free to leave a comment.

Happy Scripting!

Logging Data Using Splunk – Part 2 – Deploying the Forwarder on Windows (continued)

I promised the earlier posts We will talk a bit about how to actually configure a Splunk forwarder once you set it up on Windows. I will try to cover very briefly following:

  1. Configure Data Inputs
  2. Configure Data Output

A few “ground rules”:

  • Everything I will be talking about in this post refers to configuration files found in “<Splunk Install Path>\” folder, referred to as SPLUNK_HOME variable.
  • Configurations are read from SPLUNK_HOME\etc\system\local\ but if these files do not exist/define a specific setting, the corresponding defaults file is loaded, stored in SPLUNK_HOME\etc\system\default\. By default files in the local folder contain minimal data [e.g. host name].
  • Config file formatting : file extension is .conf, comments are prefixed with “#”, a “configuration section” has the title marked between “‘[ ]” and contains data until the next configuration section, or the end of file.

Splunk Data Inputs

Splunk explains the use of data inputs for Windows here. Data inputs are basically sources where Splunk grabs data and forwards/indexes it.

While Splunk can do so many things like WMI queries, AD monitoring, file monitoring and use python searches to index whatever you want it to, I will just show you how to make it listen to Event Logs only, personally I think the other things are stretching it a bit

If Splunk is just a side application to your organization, e.g. you use the free license, you may think his strength is in forensic analysis rather than all sorts of monitoring, which while it is nice, require more knowledge than just these basic posts of mine ;).

If you remember I told you in the last post, that while Splunk does have installation parameters, I prefer pushing the configuration after it was installed, before the first run. The reason is that I noticed the installer doesn’t really do all that it advertises, and since you, like me may want to do customizations to the config files, why not make a baseline/template “config files pack” that you push afterwards to the server.

By default a Windows Splunk install indexes some Event Logs and also uses some WMI queries, so first order of business is to make it “unindex” anything WMI/Script related. Add this to your inputs.conf file.

#Disable registry monitoring and WMI scripts
[script://$SPLUNK_HOME\bin\scripts\splunk-regmon.py]
disabled = 1

[script://$SPLUNK_HOME\bin\scripts\splunk-admon.py]
disabled = 1

# Pull event logs from the local system
# Usually disabled in favor of using WinEventLog inputs
[WMI:LocalApplication]
disabled = 1

[WMI:LocalSystem]
disabled = 1

[WMI:LocalSecurity]
disabled = 1

# Gather performance data from the local system
[WMI:LocalPhysicalDisk]
disabled = 1

[WMI:LocalProcesses]
disabled = 1

[WMI:Memory]
disabled = 1

[WMI:LocalNetwork]
disabled = 1

[WMI:CPUTime]
disabled = 1

[WMI:FreeDiskSpace]
disabled = 1

As you can see it is just a matter of setting a disabled flag. You can get a list of sources to to disable, if you go into the GUI of splunk and enable all monitoring sources then start disabling what you wish.

“Un-indexing” is finished, now we start adding what event-logs we want indexed and also set some parameters for each Event-Log.

[default]
evt_dc_name =<Add FQDN of DC here >
evt_dns_name = <Add FWDN of DC here >

The above section defines a domain controller and a DNS server for resolution of GUID/SID values in the events indexed. It is a global value, applies to all event-log sources.

[WinEventLog:Application]
disabled = 0
start_from = oldest
current_only = 0
evt_resolve_ad_obj = 1
checkpointInterval = 5

Pretty self explanatory in a way – [WinEventLog:Application] defines which application Log we are looking at. You can change the value that appears after “:” to whatever you want for example: “Directory Service”, “Powershell”,”Microsoft Office”,”Security”,”System”, any event-log name.
We set it to be enabled and to start indexing from the first event in the event log, and index all events, not just the current events (unlike a linux tail command). Evt_resolve_ad_obj enables or disables resolving of GUID/SID. CheckpointInterval is how often it polls for new data coming from the event logs.
Now you can multiply this configuration segment for as many event-logs you have defined on your system. Also if you define an event-log name that does not exist, not a problem, splunk won’t index it, it will just log an error in the event log, personally I can live with that.
Also Splunk can monitor flat files and one flat file you may be interested as a sysadmin is the windowsupdate.log file. Splunk Indexer can have a smart little application called “Windows” that can actually makes sense of those logs for you, to some extent. Here is what you should add to you inputs.conf to get that file to be monitored.

[monitor://$WINDIR\WindowsUpdate.log]
sourcetype = WindowsUpdateLog
disabled = 0

Now save this file in SPLUNK_HOME\etc\system\local\ and start/restart Splunk to see some results, or just hold that thought until the end of the post. If you followed my guide sofar, this should give you actually a Splunk Indexing Server, because all that we did was install it and configure what it indexes. Next step we make it send data out somewhere, which turns it into a forwarder and disables local indexing.

Configure Data Output

For more official Splunk info go here. For a forwarding crash course read on. We will configure Splunk to send data out to “groups”. These groups can be actually a single host, or a group of hosts (think indexing load-balancer configuration). The following will configure forwarding of all events to a host group made out of a single host. The configuration file should be outputs.conf stored in the same location as inputs.conf from before. Add this to the file:

[tcpout]
defaultGroup = &lt;group_name_ID&gt;
disabled = false

[indexAndForward]
index = true/false

[tcpout:&lt;group_name_ID&gt;]
server=&lt;IP&gt;:&lt;port&gt;
heartbeatFrequency=45
maxQueueSize=10000

First section describes the group configuration, that you detailed below and enables it. Next you can forward data and also index it locally. A forwarder does not need to keep data locally, so you set this to False.

The “tcpout: < group_name_ID>” defines a group of settings pointing to a listening server.Group_name_ID from here must match with the value you entered the first time, when you mentioned the Group_name_ID.

Server lets you define the server and listening port. The IP and port must match the IP and listening port of the Indexer.

The heartbeat frequency is basically how often the Indexer is being polled if he is alive.

maxQueueSize is by default 1000, for busy servers you may want to increase it to something more, like I did.

Now you should be done. You can start/restart splunk by starting the splunkd service from the services snap-in or run “net start splunkd” from the command line prompt on the server. If you did everything right, Splunk should be acting as a forwarder now and send data to the indexing server. If you do not see anything on the Indexer, start troubleshooting both the indexer and the forwarder. The logs from “SPLUNK_HOME\var\log\splunk\” may prove useful.

I hope this introduction was helpful to anyone trying to get a basic grasp of a Splunk setup for Windows, I wish you Happy Splunking! 🙂

Logging Data Using Splunk – Part 2 – Deploying the Forwarder on Windows

Last post I showed you how to install the Splunk Indexing Server and make it listen for data, by enabling receiving of forwarded events. That’s all very nice, but someone needs to actually send data to that port, for Splunk to index it. We are going to focus on the Windows deployment of a Forwarder, but some of the steps here are applicable, in essence to a Linux forwarder:

  • Fulfill Installation Prerequisites
  • Install Forwarder
  • Configure Forwarder

Installation Prerequisites

Some of the information mentioned here is also mentioned in the relevant Splunk documentation. I’m assuming you want Splunk to run on a domain network, and also it running on domain controllers. Essentially Splunk runs in the system using 2 services “Splunkd” and “Splunkweb”. The forwarder only needs “Splunkd” service to run. With that in mind, here is what you need to run Splunk on Windows Servers:

  • Splunk Forwarder version must be at most equal to the version of the Indexer, so your Forwarders cannot be more advanced than the Indexer. I have not tempted fate to see what breaks otherwise 😉
  • Make sure you install 32bit Splunk on 32bit OS’s and 64bit on 64bit OS’s. Splunk says 64b version offers a lot of improvements, in light of people moving to Windows 2008 server, everyone should be happy.
  • You will need the Splunk MSI package, get it from here.
  • You need a domain account that Splunk Services can run under. That account must be a Local Administrator on Servers where Splunk Forwarder will be installed. If you are focused on security, check documentation link above, for minimum requirements. You can use a GPO to enforce these settings as well.
  • To push Splunk Forwarder remotely /via script make sure the account used to run the installation can be elevated to Administrator (aka UAC does not break the install – for Windows Server 2008/ Windows 7); this is especially important in this tutorial since this will be a scripted install.
  • Make your life easier and keep the Splunk.msi on a network share along with any installation scripts. Also secure that share as best you can, since some data is in clear text.

Install the Forwarder

For installing the forwarder we will make a command line install. The installer allows more customization via the CLI than via all the install menus. For reference you can take a look here for all CLI switches, but note that not all switches work as advertised. There are a lot of CLI switches designed to customize Splunk upon on installation, but since some of them do not work and the fact that Splunk can be customized after the installation, I used only switches that worked and I could not configure after the installation. Here’s the magic, that you need to put on a Windows NT batch file (“.bat”) and run it.

::Stop all splunk services
net stop splunkd
net stop splunkweb
::Remove all splunk versions
start /wait MsiExec.exe /uninstall {60ad9785-709f-4b4d-ac19-91cbe0ab7614} /passive
start /wait MsiExec.exe /uninstall {a7579aaa-db6b-46ce-90ca-d8f553481bcc} /passive
start /wait MsiExec.exe /uninstall {2c0fae08-7c9c-40f9-ba21-82a2aad07f0d} /passive

::Map drive to splunk install path
net use /delete S:
net use S: <map network path of splunk executable>

::Execute installation string, minimal configuration
start /wait msiexec.exe /i S:\splunk-4.0.9-74233-x86-release.msi INSTALLDIR="%ProgramFiles%\Splunk" RBG_LOGON_INFO_USER_CONTEXT=2 IS_NET_API_LOGON_USERNAME="<domain\SplunkServiceUser>" IS_NET_API_LOGON_PASSWORD="<Password>" LAUNCHSPLUNK=0 AUTOSTARTSERVICE_SPLUNKD=1 AUTOSTARTSERVICE_SPLUNKWEB=0 /passive

Breaking the code down really quick:

  • Stop splunk services, just to make sure. You can foolproof the code by also forcefully killing Splunk related processes.
  • Use the “uninstall current version” section to rid yourself of previous versions of Splunk. This will be a growing list of commands…because:

    • Important Note: The Installation ID of Splunk is different from 32b version to the 64b version, and from different 32b/64b versions, so make sure you get the Installation ID correctly from the registry or however you know. Reg key is here HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
  • The specific parameters related to Splunk are as follows
    • Specify installation directory – INSTALLDIR
    • Specify how services run (Local System or Domain Account – we used Domain Account – RBG_LOGON_INFO_USER_CONTEXT=2 )
    • Specify credentials used (IS_NET_API_LOGON_USERNAME, IS_NET_API_LOGON_PASSWORD)
    • Specify what happens to splunk after installation is finished and status of the Splunk Services, we want splunk to do nothing and we don’t need Splunkweb (LAUNCHSPLUNK, AUTOSTARTSERVICE_SPLUNKD, AUTOSTARTSERVICE_SPLUNKWEB)
  • The last /passive switch is typical to the MSI installer, use /quiet if you prefer. Also you do not need to reboot after a Splunk Install/Uninstall.

Improvements to this piece of NT batch code? Yes we can

  • Remove any values from the Username and Password field and replace the parameters with:
    • IS_NET_API_LOGON_USERNAME=”%1″
    • IS_NET_API_LOGON_PASSWORD=”%2″
  • Save the script above to a batch file, SplunkDeploy.bat for example, and run the batch file like this:
    • SplunkDeploy.bat domain\SplunkServiceAccount reallyhardpasssword where you replace the bold text with your specific Splunk account credentials.
    • This ensures that no passwords are kept in clear text, quite a big no no considering this sort of account kind of owns all computers on the domain, one way or another.
  • At this point Splunk is installed and configured with the default settings. Notice what we have done now relates very little to the Forwarding role Splunk will have, this will be addressed in the Configuration section. As I don’t really like the default configuration, and since going into explaining why, requires another post and a bit much of reading attention I hope you will stay tuned for the sequel to Part 2, IMO the most complex part of the series 😉