This is actually the first time I’ve even heard of opportunistic TLS, I’m used to seeing S/MIME and PGP when reading about email encryption.  What I like about this is encryption/decryption is done on the server side so the users don’t have to do anything different when sending emails and we don’t have to issue a certificate to each user and manage the keys.

If you’re using Exchange Server 2007, opportunistic TLS is already enabled by default.  You can check this by entering Get-SendConnector “Send Connector Name” | Format-List in the Exchange Management Shell.  Look for the IgnoreStartTLS parameter, if it’s set to false then opportunistic TLS is enabled.

To check whether a server supports TLS, telnet to the server on port 25 and check if the server supports the STARTTLS command, for example:

telnet mail.global.frontbridge.com 25

This server supports TLS

Here’s an example of the header of an email that was delivered with TLS enabled (I modified the IP addresses and names for privacy reasons):

Received: from mailgateway01 (1.2.3.4) by mailserver01.domain.com (1.2.3.5)
with Microsoft SMTP Server (TLS) id 8.1.263.0; Mon, 16 Mar 2009 18:05:18
-0400
Received: from mail.global.frontbridge.com ([65.55.88.22]) by mail.somedomain.com
([1.2.3.4]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS:
TLSv1/SSLv3,128bits,AES128-SHA) id 06456c96000057da for <jdoe@microsoft.com>;
Mon, 16 Mar 2009 18:05:16 -0500

Step 1.  Copy the contents of the Office 2007 installation CD (or package) to a network share (eg. \\server\Office12).

Step 2.  Run the Office Customization Tool and create a setup customization file (I got these instructions from a BDD 2007 document on Microsoft’s website).

1. Run the Office Customization Tool
   1. Go to Start->Run
   2. Type the following command:  \\server\Office12\setup.exe /admin
2. Create a setup customization file
   1. In Office Customization Tool, Click OK to create a new setup file.
   2. Specify the Installation Path, Organization Name
   3. Add the network share location of the Office 2007 Installation Files Shared Folder. \\server\Office12
   4. Specify the Product Key and Accept the License Agreement. And Modify the Display Options.
   5. Configure other options
   6. Finally, Click File, Save As, and save the Setup Customization File to Office12\Updates Folder
   7. Close the Office Customization Tool

Step 3. Download and install PowerShell.

Step 4. Download and install PsExec.

Step 5. Open a text editor (WordPad or Notepad is fine) and use the sample script below.  Save the file as office_2007_install.ps1.

$hostname = “comp1″,”comp2″,”comp3″

foreach ($i in $hostname)
{
&”c:\psexec\psexec.exe” -s \\$i \\server\office12\setup.exe /adminfile cust_file.msp
}

Replace comp1…comp3 with the computer’s hostname or IP addresss.

Note: You can also pull the list of computers/IP addresses from a text file (one entry per line) by doing something like $hostname = Get-Content c:\computers.txt.

Step 6. Schedule the script in Task Scheduler

c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe -noexit “c:\office_2007_install.ps1“

Some suggestions:

• Let your users know ahead of time when you are planning on upgrading their Office software.  They may be working on a project and can’t afford to lose any time adjusting to the new version.
• Send these links (Interactive 2003 to 2007 Command Reference Guide) to your users before you upgrade their Office applications so there are no surprises when they first use Office 2007:
  • Word: http://office.microsoft.com/en-us/word/HA100744321033.aspx
  • Excel: http://office.microsoft.com/en-us/excel/HA101491511033.aspx
  • PowerPoint: http://office.microsoft.com/en-us/powerpoint/HA101490761033.aspx
  • Outlook: http://office.microsoft.com/en-us/outlook/HA102221621033.aspx
• Start with a small group of computers so if you discover a problem (eg. software conflict) there will be minimal interruption.  For example, start with 5 computers and if there are no problems then increase it to 10 computers for the next batch, then 20, then 40, and so on.

You’ve probably seen this message before while working with VMware, especially if you’ve done physical to virtual migrations.

As a best practice, it is recommended to always start with only 1 vCPU when creating virtual machines and only increase the number of vCPUs if you think it’s necessary and if the virtual machine is actually running applications that can utilize multiple processors to avoid wasting resources.

Increasing the number of processors from 1 to 2 or more is actually not a problem with Windows Server 2003 because it will automatically change the HAL to ACPI Multiprocessor PC.  But setting the number of virtual processors back to 1 won’t automatically change the Windows 2003 HAL back to ACPI Uniprocessor PC.

According to Microsoft, “If you run a multiprocessor HAL with only a single processor installed, the computer typically works as expected, and there is little or no affect on performance.”  But if you’re like me and just want to be absolutely sure that there won’t be issues, switching back to the uniprocessor HAL in Windows Server 2003 is pretty easy:

1. Make sure you have at least Windows Server 2003 Service Pack 2 installed.
2. Shut down the virtual machine.
3. Change number of virtual processors to 1.
4. Power on the virtual machine.
5. In Windows, go to Device Manager -> Computer.
6. Right-click “ACPI Multiprocessor PC” and choose “Update Driver…“.
7. Select “No, not this time” option -> “Install from a list or specific location” -> “Don’t search.  I will choose the driver to install.” -> select “ACPI Uniprocessor PC.”
8. Reboot the virtual machine.

That’s it! You’re all set!

I wanted to send a copy of the syslog messages for SSH to my central syslog server so I can easily keep track of login attempts to my server from the outside.

Here are the steps:

1. Open /etc/rsyslog.conf and  add this line:

   • authpriv.* @remote_server_ip_address

2. Restart the rsyslog service: /etc/init.d/rsyslog restart

Change “authpriv.*” to “*.*” if you wish to send a copy of all the syslog messages to the remote server.

I connect to our network over a VPN connection using Cisco VPN Client but I first have to be logged in to Windows to do this.  I want to be able to log in with my domain account directly then log in to the VPN as it is more convenient so here’s what I did to update the local cache for my domain profile:

1. Log in as local Administrator.
2. Log in to the VPN.
3. While still connected to the VPN, do a “Run As” on a program.  In my case, I did a “Run As” with Outlook (press shift+right mouse click on the program’s icon, choose the option “Run As…” -> “The following user:” myDomain\username -> enter your current domain password) and the program should open using the profile of the user you wanted to run as.
4. Log off (which will also disconnect the VPN connection).
5. Log back in to your domain account using your current domain password and it should take it.

If you’re already able to log in with the cached password, but your current domain password is different from the cached password, while connected to the VPN you can just press CTRL+ALT+DEL, choose the option “Lock Computer”, and then unlock it but this time using your current domain password and that should update the cached password.

1. PXE boot on the computer you wish to image.
2. At the first prompt, choose the option “Exit to command Prompt.”
3. Map a network drive to your distribution share and run ImageX.  Example:
   1. net use x: \\bddserver\distribution
   2. cd x:\Tools\x86
   3. imagex /capture c: x:\Captures\ImageName.wim “Computer Image Description”

Source:  http://lukenotley.wordpress.com/2007/05/20/bdd-2007-how-to-capture-a-reference-computer-image/

Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed.  Disconnect all previous connections to the server or shared resource and try again.”

I get this once in a while when working on files remotely.  To make it go away, do the following:

1. Go to Start->Run, type in cmd and hit Enter.
2. Type net use to view all mapped network shares.
3. Type net use \\network_share /del to disconnect that specific network share or  type net use * /del to disconnect all network shares.

I got this warning message last week while testing a group policy object to run a small program from a network drive when users log in to the domain.

After some googling, it turned out that this feature was added in Windows XP Service Pack 2 and it checks whether the program has a digital signature attached.

To prevent this from appearing do the following:

1. Open the Group Policy management console (Start->Run->gpedit.msc)
2. Go to User Configuration->Administrative Templates->Windows Components->Attachment Manager
3. Enable “Inclusion list for moderate risk file types“
4. Add .exe to the list

Source: http://davestechshop.net/archive/2006/10/30/IE7PublisherCouldNotBeVerified.aspx