http://support.microsoft.com/kb/2509007

Once I installed the patch Software updates were downloaded and installed to the capture computer. This issue seems to affect only Windows 7 captures and with software update packages containing more than 80 patches.

I had to find the problem somewhere else, and I did. Apparently the settings in the GUI didn’t get written to Webdav_schema.xml, and someone was kind enough to document how to change them, so here is the link for future reference.

http://scug.dk/blogs/configurationmanager/archive/2009/12/30/webdav-fails-on-windows-server-2008-r2.aspx

So to get this working you need to set option 66 and option 67 in your DHCP server.

The options should be set to as following:

Option 66 (boot server host name): IP of your server, ex 10.0.0.1

Option 67 (bootfile name): SMSBoot\boot.sdi

There are many guides out there on this topic, but most don’t need or want to understand the inner workings of DHCP, they just want the filenames. So there you go.

Things that really stuck were the session on Microsoft Intune by Salcom Group and the 7 ways to break into Windows 7 by Sami Laiho from Sovelto and Petri Paavola from Aalto Yliopisto and a really special session by Sami Laiho talking about WIOSKI.

Microsoft Intune

This is going to be big for any small companies. Remember I said this. Not because I’m really into cloud computing yet but the fact that any small-midsize company can easily get a management system for their computers.

Reporting is a big part of todays security, so getting reports on how many of your computers are patched is actually a big deal.

But the thing that I liked most about Intune was the fact that the license includes a copy of Windows 7 Enterprise, and when a new Windows version comes along you have the privilege to upgrade. This will effectively give small size businesses a chance to get BitLocker in use. And from a security perspective that’s a big deal.

One of the really great things is that since the whole system operates from the cloud the systems administrator can work from anywhere.

The remote assist feature is also a part of Intune but my personal opinion is that you’d be better of with something like TeamViewer.

Intune also includes Microsoft’s Forefront Endpoint protection, so technically you could ditch your current antivirus. I haven’t tried FEP but many who have says it can actually protect your computer from the malware and viruses you throw at it.

The pricing also looks quite affordable, at 11€ / workstation / month it’s really not that bad. You get a great system and you can ditch some costs, like Antivirus licenses and you’ll cut the management costs since you don’t have to keep your own servers. And that is a cost saver for SMB’s, since they are rarely able to keep them up to date and secured properly anyway.

You can find information about Intune here http://www.microsoft.com/windows/windowsintune/pc-management.aspx

7 ways to break into Windows 7

This was a really interesting seminar, thanks to Sami Laiho and Petri Paavola for this one, these guys really know how to take an audience.

The ways they break in isn’t in any way new, most of us know that if the systems physical security is compromised in any way, you can’t trust the system anymore.

The interesting part is that with simple disk encryption, like Bitlocker, most of the hacks can be stopped.

The hacks they did were simply to replace the Sticky keys (sethc.exe), Displayswitch.exe to cmd.exe. This way when Windows boots just press Windows+P or 5xShift to get a command prompt running with system privileges. After that just use net.exe to add your administrative user and the computer is yours.

This could, as I said be prevented with BitLocker because you can’t get to the encrypted drive and modify it from WinPE or a Linux LiveCD.

Even if BitLocker is enabled there are ways in if you don’t use pre-boot PIN codes. And since central management for the PIN code isn’t available yet many haven’t  applied it. This hack was using a Linux distribution to access the computer by writing directly to the memory, using the FireWire port. The scary thing is that this isn’t something that’s only available on Windows based PC’s. Any computer that has a Firewire port activated can be hacked using the same tools.

In Windows Administrators can use Group policies to force Firewire drivers never to install but I’m not sure how to get this done in any other environment.

And if you think you’re safe because you don’t have a Firewire port, think again. There are PCMCIA cards supplying this port and any modern operating system will without a question install the drivers unless it’s denied to do so.

WIOSKI

This is basically a really smart way to run a KIOSK computer. What Sami has done is put together a bunch of scripts using only standard Microsoft techniques. It works by using two VHD’s (Virtual Hard drives). Using one differential and one master image.

Basically you first operate the master one, install anything you need and after that reboot the computer to the differential VHD. The next time the computer is booted anything on the differential drive get’s trashed.

So every reboot you have a fresh start and the computer is just as it was when the administration installed and approved it.

The installation is dead simple and the performance isn’t bad in any way since no virtualization is done.

The only downside is that the only Windows versions able to boot from a VHD file is Windows 7 Enterprise OR Ultimate. So you need a license for one of them.

Anyway, you can find the Wioski medias and a instruction video from the site http://www.wioski.com.

Thanks again for a great couple of days to the organizers.

After some searching on the web I found a solution, use the Subordinate Certification Authority template. This is not ideal but it works. So anyone out there getting errors like

The certificate is not valid for the requested usage. 0x800b0110

Can use the Subordinate CA to sign the certificate in question.

If you have a better solution please post a comment.

This is a highly customized process for the migration. I suggest you test everything here in your test lab before you even attempt to run it in production. All advice is provided as is and if something goes wrong you are on your own.

Image 1 displays a simplified setup of an Exchange system where we have two client access servers in a simple cluster and three backend mailbox servers.

What this article does not discuss

I will not go into any email routing so you need to make sure the email is routed correctly to your backend servers. This article will only take a look at activating the user mailbox in Exchange 2010 and synchronizing the IMAP account from the Linux server to the Exchange server.

Software and information

To successfully follow this article you need to know how to reset the IMAP users passwords and you need to know their usernames. That’s not something I will go into here, we used scripts to reset the passwords but you might want to do it another way.

You also need to install IMAPSync on the Linux server, it doesn’t necessarily have to be the one hosting the mailboxes, it could be another server. We used a third server for this because it was easier to install IMAPSync on a fresh CentOS 5 server than getting it set up on the old Linux server. The IMAPSync .rpm is available in the rpmforge repository. More information on that here http://dag.wieers.com/rpm/.

Simple walkthrough of the process

The HUB servers have a common FQDN, like exchange.domain.com. The HUB servers need to have the IMAP service started since this is the interface for the transfer. Normally this service is stopped in Exchange servers.

Our Linux server is running IMAP so we can connect to it without making any changes to it.

The flowchart in image 2 shows us the process

As I said above, you need to take care of the email routing before you activate mailboxes. Once the mailbox is activated all internal email from other Exchange users will go to the Exchange mailbox.

So to prepare we need to file the users we want to move in tables to be exported to comma separated values. We used Excel but you may use whatever you want. The file was set up like this

This table was collected from local support engineers so they were able to define the users they wanted us to move. This article assumes the username for the Linux server is the whole SMTP address. Yours might differ and you would have to adapt this to any of my simple scripts.

The files needed for the servers

For the Exchange Server we need all of the columns so export everything to a CSV file. After export the file should look something like this

uname,alias,smtp
user1,Fname.Sname,fname.sname@domain.com
user2,Fname2.Sname2,fname2.sname2@domain.com

Assuming your alias combined with the domain.com is the username on the Linux server you would only need to export the Alias column to a file which should look something like this

Fname.Sname
Fname2.Sname2

When you have the two files, for simplicity let’s call them Exchange.csv and Linux.txt, copy them to the servers. The Linux.txt file should locate on the server you want to run IMAPSync from.

Activating mailboxes and setting the permissions

To move email we are going to use one special purpose account created only to move other users email. So open up your Active Directory Users and Computers and create a simple domain user account. During this example I’ll call this user Exch_mig_user. You can call it anything, or if you really want to, you can use an existing account.

Once you have an suitable account to set the Full access permissions for we can go ahead and create some mailboxes. So log into your mailbox server and fire up Exchange management shell.

The Exchange.csv file should already be located on the server, let’s say it’s in C:\.

To activate the mailboxes we run the following PowerShell command

PS C:\>Import-CSV C:\Exchange.csv | foreach-object{Enable-Mailbox –Identity $_.uname –Alias $_.alias –PrimarySMTPAddress $_.smtp}

This imports our CSV file and uses the values from the file to fill in the blanks in our Enable-Mailbox command. If you want to see what this command would do before using it just ad –WhatIF after $_.smtp. –WhatIf can be used with any of the PowerShell commands here.

After this we need to set the permissions on the mailboxes so the Exch_mig_user account will be able to access the mailbox.

Once again using PowerShell we run

PS C:\>Import-CSV Exchange.csv |foreach-object{Add-MailBoxPermission $_.Alias –user Exch_mig_user –AccessRights FullAccess}

Again, using –WhatIf will show you what would be done.

After running this we will be able to access any of the user accounts defined in the Exchange.csv file using the Exch_mig_user account. This is done so we don’t have to reset any user passwords in Active directory.

After you’re done move over to the Linux server but do not delete the Exchange.csv file, we will use it again later.

Reset Linux passwords

Looking at the flowchart in Image 2 this is where we reset the passwords for the Linux email users so they wont be able to log into the old system anymore and so we can access their email data. As I said before every system here can be different so I’m going to leave this part to you. You can script it, do it manually or have someone else do it. Just set the password to something useful if the server will continue to be active so it wont get hacked.

Using IMAPSync

Now that we have our Exchange accounts active and our Linux account passwords changed we can start the sync process. Notice the word sync, as this will not remove any email from the old server. It will sync them and if you run it again only new items will be moved.

So in our Linux server we have our Linux.txt file containing the First name and Surname of the users we are going to move.

The simple bash script I used looks like this

#!/bin/bash
logfile="synclog.txt"
testlog="/tmp/testlog.txt"
host1=linuximap.domain.com
#host1 is Source
host2=exchange.domain.com
#host2 is Dest
domain=domain.com
#domain is where email account is #everything after @ symbol ######
Do not modify past here #######################################
date=`date +%X_-_%x`
echo "" >> $logfile echo "————————————" >> $logfile
echo "IMAPSync started.. $date" >> $logfile
echo "" >> $logfile
{ while IFS=’;’ read u1; do
user=$u1"@"$domain
echo "Syncing User $user"
date=`date +%X_-_%x`
echo "Start Syncing User $u1"
echo "Starting $u1 $date" >> $logfile
imapsync –buffersize 8192000 –nosyncacls –subscribe –syncinternaldates –noauthmd5 –host1 $host1 –user1 "$user" –password1 TheLinuxPassword –ssl1 –port1 993 –host2 $host2 –user2 AD_DOMAINNAME/Exch_mig_user/$u1 –password2 Exch_mig_user_PASSWORD
date=`date +%X_-_%x`
echo "User $user done" echo "Finished $user $date" >> $logfile
echo "" >> $logfile
done ; } < Linux.txt

date=`date +%X_-_%x`
echo "" >> $logfile echo "IMAPSync Finished.. $date" >> $logfile
echo "————————————" >> $logfile

As with any script downloaded from the internet, read it, understand it and use it at your own peril!

Since we have changed all Linux users passwords to a specific password we can use a static password. If you want to use different passwords for different accounts you need to modify the script and the Linux.txt file.

Also the user used to access the Exchange mailboxes is the same for every account so the password can be static there to.

You need to change the following in the script

• TheLinuxPassword
• AD_DOMAINNAME
• Exch_mig_user_PASSWORD

Once they are set to your private settings you can run the script and it will sync the users from the IMAP server to Exchange Server via IMAP. Every account synced will be logged to the synclog.txt file.

Once the synchronization is done it’s time to once again go over to the Exchange server and remove the Full Access Permissions for the Exch_mig_user account.

Removing the full access permissions

Now that we have synced the defined users mail from our old system to our new system it’s time to remove the full access permissions of the account we used while moving email.

Again open the Exchange Management shell and run the following

PS C:\>Import-CSV Exchange.csv | foreach-object{Remove-MailboxPermission $_.Alias –user Exch_mig_user –AccessRights FullAccess –confirm: $false}

The –confirm: $false statement is there so we don’t have to confirm every permission change. If you move hundreds of users a time you don’t want to confirm this for every mailbox.

Once the script is done you should be done.

Summary

This might not be the most effective or the best way to move users from IMAP to Exchange, but it works and it does not cost anything but time spent on it. One problem is that IMAP folders will be synced one-to-one so if you have subfolders etc. your Exchange mailbox might get a little cluttered. But users have a tendency to clean it up, and we see to it that they get everything with them from the old system.

If you do use this method I’d really like to hear about it and if you have any questions feel free to ask. You can use comments here or send me an message using the contact page.

TeamViewer to the rescue

This is just one wonderful piece of software, never again will I have to get away from the comfort of my home office to fix a friends computer. I use TeamViewer for every last one of these problems.
There are two reasons for this, the first one is in non-commercial use TeamViewer is free as in beer and the second is the variety of platforms you can run TeamViewer on. TeamViewer runs on Windows, Mac, Linux and mobile devices. Granted I wouldn’t use my iPhone to support someone on a 24″ monitor but it is be possible.
Using it is so easy even your 90-year old grandma can use it. Just have them download and start up the QuickSupport version of TeamViewer and you can install the All-In-One full version.
From your client you will get the sessionID and the password, tap them into your full client and you are connected to their screen.
I promise you will save a lot of time using this. What ever your personal support incidents might be. Just remember it wont work if their problem is the connection to the network

Sometimes you really don’t have the time to wait for the hour to pass by. I’ve found two ways to speed this up, if you know something I don’t please inform me in the comments.

Speed up for lab environments

This first one is NOT recommended in production environments. If however you use a test environment this is a nice way to speed up the PXE service once and for all.

On the server running PXE and Windows Deployment Services (WDS) open regedit and add the following key

HKLM\Software\Microsoft\SMS\PXE\CacheExpire

The type should be DWORD and the Value 300 for 5 minutes in decimal. Without this key the standard cache time is 3600 seconds as mentioned above.

Speed up for production environments

This way is not in any way permanent. And it’s really easy when you need to get an install going quickly.

Just open services on the server running WDS and PXE service point. Find Windows Deployment Services and restart the service. Once restarted the cache is cleared and the bare metal system should go to PXE boot immediately instead of abortpxe.

Hope you found this useful and don’t hesitate to comment if you did.

Checking the logs on the Client Access server pointed me to look at permissions and it seems like some accounts have disabled the inherited security rights. This is the problem since Exchange can’t access the account information.

To check this you use Active Directory Users and Computers and open the user in question. Open the Security tab and press Advanced. On the open window you should se the “Include inheritable permissions from this object’s parent”. If it’s not selected your Active sync will fail.

Hope this shortens someone’s troubleshooting session.