Update Outlook Safe Sender List via GPO

I had a client with the need to update the Outlook Safe Sender list in Outlook's Junk Email settings across about 100 end users. The list had only a couple of addresses and we did not want to overwrite whatever list was already in place for each end user. They have an Active Directory environment and have a couple of sites. They also use Outlook 2007 and 2010. So the question became, how can this be done through Group Policy? Do we have to run an MSP package or can we just use Administrative templates to set the information?

I found the Office 2007 and Office 2010 Administrative GPOs on Microsoft's site. I downloaded them and placed them in the correct location. These GPOs are for Windows 2003 or Windows 2008 Active Directory environments. Don't forget to copy the ADML files in, too. You will get errors when attempting to modify a GPO with the Office ADMX Administrative templates.

I made the appropraite changes in the Outlook GPO. The Junk Mail filter is located under User Configuration > Administrative Templates > Microsoft Office Outlook (version here) > Tools | Options > Preferences > Junk E-mail. I enabled the list setting and pointed to the location of the list and allowed the list to be updated, instead of overwritten, among a few other options. I attempted to have the GPO push to my test computers and only a couple of the settings took effect. The list did not take effect. I researched the issue and found this is a common problem.

I found this Technet thread -

http://social.technet.microsoft.com/Forums/sr-Latn-CS/outlook/thread/0ddcf321-9158-4078-ac83-45b33ef98266 - and discovered my problem. The registry keys were not getting created through the GPO and therefore, no list was being applied. I created the keys using the Group Policy Preferences for the user and successfully pushed the list to the test computers.

 

The following registry keys are required for Outlook Safe Sender lists to be populated inside:

 

HKEY_CURRENT_USER\Software\Policies\Microsoft\office\14.0\outlook\options\mail

"JunkMailImportAppend" DWORD = 1 NOTE: This is DWORD value. “1” is for Appending. “0” is for Overwrite.
"JunkMailSafeSendersFile" SZ = "C:\SafeSenders.txt" NOTE: String value is set to filepath of txt file
“JunkMailImportLists" DWORD = 1 NOTE: 1 = Enabled 0 = Disabled

 

Upon import of the list the JunkMailImportLists value will automatically change to 0. If this registry entry is set to 1 from Group Policy it will continue to import the list at each logon. Rest assured, it will not create duplicate addresses for each subsequent logon. If you are using Outlook 2007, simply replace the 14.0 with 12.0 in the registry path. The same values work for Office 2007

 

I used the option to append to the current list so that if anyone has a specific sender in their list, my imports won't affect their individual settings. This is important to note, as some end users can create a rather long list of acceptable safe senders, especially if they subscribe to mailing lists. Many times these can get caught in Outlook's Junk Mail. Overwriting that list may cause more headaches. The best to avoid that pitfall is understanding the needs of the end users affected by the anticipated changes.

 

The other option available mentioned in the thread is to update the Exchange Server with a few cmdlets. My customer uses a hosted Exchange environment, so this was not an option for us. Implementing the registry settings was simple enough and can be maintained easily.

 

Credit goes to Jahawk at Microsoft for showing this information in the Technet thread.

Service Desk Manager's Snacks - How to Determine Priority

This is a snack of information about Service Desk Management. Today's snack has to do with prioritizing issues using an ITIL concept of combining impact and urgency to determine priority. One of the core responsibilities as a Service Desk Manager is determining priority of incoming tickets. We all know our customers well. Their problem is the only we need to be looking at, regardless of who else has problems, right? How do you appropriately determine the priority of the issues coming into your ticketing system? I handle this using a combination of two questions. What is the impact? And what is urgency? Together these two fields create the priority. Our customers may not like what it translates into, but that is how we are able to determine where to allocate resources.

So what does impact and urgency mean? What values should you apply to them that makes sense in your environment? How do these really help me determine the priority? Glad you asked. Impact has to do with effect on the customer's ability to perform their job function. Some of the values I typically use for impact are individual, department, building, site, and company wide. Each of these values help me identify the number of resources I can most likely expect to spend on the issue. I typically use none, normal, medium, high, and critical for urgency. Each of these values help me identify the level at which I should respond. Together they tell me how many resources I should expect to use to resolve and work on the issue as well as what quickness do I need to respond.

To create the priority I create a matrix of priority results based on impact and urgency. The combination of impact plus urgency equals priority. I have created an example of what a matrix might look like using the values I provided of Impact and Urgency and making up my own values for priority.

As you can see from the matrix we have an appropriate priority based on the combination of impact and urgency. This design may not fit within your organization or processes so you may have to modify portions of it. The goal of this snack is to help you efficiently prioritize the tickets coming into your service desk so as to keep costs lower resulting in a direct impact on the Service Desk's ability to respond appropriately to the issues it receives. Keeping costs lower through efficient staffing as a result of effective prioritization has a direct and positive impact to the company's bottom line.

I implement service desk and infrastructure management software in many organizations across the country. Part of my job to is to help those organizations improve their service desk processes. This is one of the greatest impacts I see with my customers. They are able to implement it quickly and see immediate results.

How to Uninstall Almost Any Application Silently over the Network

There are a lot of times when you need to silently uninstall an application from computers in your network that should not be installed. These are what I refer to as "unapproved applications". Yeah, I know... It's original, isn't it? At any rate, these applications need to be removed from one or more computers in your network. You did not install them and you do not have the installation source files. How can this be done efficiently without walking to each desk or staying late?

Almost every application these days has an uninstall string stored in the registry. This information is available in the registry and in plain text. Most of the time, the default uninstall string is based on prompting the computer user for questions like, "Are you sure you want to remove this product?" These questions are annoying from a system admin perspective, because you will most likely not be there to click on Yes, nor do you want to be there to click Yes. The uninstall strings can be slightly modified to suppress those questions and allow the software to be uninstalled silently or with just a progress bar.

Let's look and see where to find those elusive uninstall strings. The first place to start is in the "Add/Remove Programs" for Windows XP or "Programs and Features" for Windows Vista/7. Open your appropriate Control Panel item and find the application that needs to be removed. Document the exact name of the application. For exmple, if Adobe Reader X is the application to remove it is listed in my system as "Adobe Reader X (10.1.0)".


The next step will involve searching the registry. Now is the time for my disclaimer.

NOTE - Modifying the registry is dangerous. Any changes made as benign as they may appear can cause your system to become unstable or unusable. Proceed at your own risk. I am not responsible for any problems that may occur from you entering your registry.

Now that's out of the way, let's get down to business. To open the registry open a Run Command and type "regedit". From within the regsitry go to the following location based on your OS architecture.

 - Windows XP/Vista/7 32-bit -
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall


- Windows XP/Vista/7 64-bit with 32-bit software -
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall


- Windows XP/Vista/7 64-bit with 64-bit software -
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

Search the registry from the Uninstall folder for the exact information documented from the Add/Remove Programs or Programs and Features. You do not need to enable the Match Whole String Only check box.

Once you find the entry look for a string value labeled UninstallString. That value needs to be copied out to a text document for modification later. The example I have been using for this exercise is Adobe Reader X. This may not necessarily be a piece of software that gets uninstalled in your environment, but the concepts are still the same across the board in regards to MSI uninstalls.

The uninstall string for Adobe Reader X should look something like this when copied out of the registry - "MsiExec.exe /I{AC76BA86-7AD7-1033-7B44-AA1000000001}". We are going to write a script that will use this information to execute a completely silent uninstall of Adobe Reader X.


**********************************BEGIN SCRIPT**************************************
Set Local

REM Identify if the computer is 32-bit or 64-bit
IF NOT "%ProgramFiles(x86)%"=="" (goto ARP64) else (goto ARP86)

REM Operating system is X64. Check for Adobe Reader in emulated Wow6432 uninstall key
:ARP64
reg query HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432NODE\Microsoft\Windows\CurrentVersion\Uninstall\{AC76BA86-7AD7-1033-7B44-AA1000000001}
if NOT %errorlevel%==1 (goto End) else (goto RemoveAdobe)

REM Operating system is X86. Check for Adobe Reader
:ARP86
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{AC76BA86-7AD7-1033-7B44-AA1000000001}
if %errorlevel%==1 (goto RemoveAdobe) else (goto End)

REM If 1 returned, the product was not found. Run uninstall string here.
:RemoveAdobe
start /wait %windir%\system32\msiexec.exe MsiExec.exe /x{AC76BA86-7AD7-1033-7B44-AA1000000001} /qn

REM If 0 or other was returned, the product was found or another error occurred. Do nothing.
:End

End Local
*****************************************END SCRIPT***********************************

Note the change to the Uninstall String we copied from the registry. It was "MsiExec.exe /I{AC76BA86-7AD7-1033-7B44-AA1000000001}". It is now in the script as "MsiExec.exe /x{AC76BA86-7AD7-1033-7B44-AA1000000001} /qn". The reason for the change is due to the syntax required for msiexec.exe to do its magic. The script can be deployed through Group Policy as Logon or Logoff script.


Below is a list of common syntax usages and their meanings for msiexec.exe.

Installation Options
msiexec /i <MSI File Location> /qb
- This installs an MSI based application in quiet mode with a progress bar and a cancel button

msiexec /i <MSI File Location> /qb-
- This installs an MSI based application in quiet mode with a progress bar and without a cancel button

msiexec /i <MSI File Location> /qn
- This installs an MSI based application in quiet mode with no visible indication an application is being installed

Removal Options
msiexec /x <MSI File Location> /qb
- This removes an MSI based application in quiet mode with a progress bar and a cancel button

msiexec /x <MSI File Location> /qb-
- This removes an MSI based application in quiet mode with a progress bar and without a cancel button

msiexec /x <MSI File Location> /qn
- This removes an MSI based application in quiet mode with no visible indication an application is being installed

Logging can be enabled by adding a /l to the end of the the msiexec line followed by a location to store the log file.
Eample - msiexec /i <MSI File Location> /qn /l %temp%\MyApplicationLog.log

This example installs the application completely silent and creates a log file in my user profile's temp folder called MyApplicationLog.log. The user profile's temp folder is located in "C:\Documents and Settings\<userprofile>\Local Settings\Temp" for Windows XP or "C:\Users\<userprofile>\AppData\Local\Temp" for Windows 7.

Using this methodology you can uninstall almost any application on your network that uses the MSI Installer engine. If the application in question uses another type of engine you may need to search Google for a silent option for the application. Chances are you are not the first one to ask the question. Some ideas to keep in mind for those other engines usually use something like /s or /q, /silent, or even /verysilent.

Expert's Guide to A Successful Office 2010 Deployment

So you're finally making the leap to Office 2010. On a personal note, I think Office 2010 is probably the best version of Office Microsoft has ever produced. Sure, it has its bugs, but what software is bug free? At any rate, on to why you're here; Installing Microsoft Office 2010 across your network without sitting at each desk.

The method I am using assumes you are using a Volume License or KMS licensed copy of Office 2010. This scenario is based on a single site network using Active Directory and no deployment tools. The script assumes a mixture of 64-bit and 32-bit systems installing the 32-bit version of Office 2010 Professional Plus. The example server names and shares are purely fictional and may need to be changed to meet your own environment. This article you are familiar with Active Directory management.

The first thing we need to look at is what kind of deployment tools are at your disposal? Do you have a nice system like System Center Configuration Manager, Numara's Asset Management Platform, ScriptLogic's DesktopAuthority, or something else, even a manual deployment option? If you don't have any of these nice deployment tools, it's ok. You can get this done without them. It will just take a little more effort and you won't have the nice reporting that comes with some of those other systems. I'm going to assume you have no spiffy tools other than your extremely talented and creative Network Admin brain.

We also need to look at storage space for the source files and also ensure your systems can handle the Microsoft Office 2010 system requirements. Unfortunately, I cannot help you with this aspect. I have to expect you know your network better than me. So, moving along we need to look at the storage space required on the server. Make sure you have at least 1.5GB of free disk space on a network server that can store the source files.

So far, we have identified the best recommendation is to use a Volume License or KMS License copy of Microsoft Office 2010 for this installation method. The next step is to identify the deployment tools available to use in your location. For the benefits of those without, I am writing from the point of view without a tool to use. Following our deployment tool selection step is to identify the server that will house the installation source files. To create the installation source simply copy the entire contents of the Office 2010 DVD to a network share. For example, if you server name is SERVER1 and you create an installation share called Office2010 then copy the contents to the Office2010 folder on your server. Once the copy is complete the files should be viewable from \\SERVER1\Office2010. Your actual server name and share may be different.

Let’s look at the options for modifying your setup. Office 2010 includes a setup customization tool and a config.xml file to customize your setup. The setup tool can be accessed by running \\SERVER1\Office2010\Setup.exe /admin from the Run command. The Config.xml is located in ProPlus.WW folder. Go to http://technet.microsoft.com/en-us/library/cc179195.aspx#ConfigxmlElementReference to learn the available elements of the config.xml file for Office 2010. The areas of the Administrative Setup tool I am going to cover are the minimum recommended options to change for a successful network deployment.

1.      Set the program installation folder and company name. The default path is C:\Programs Files\Microsoft Office. I recommend using this path so as to reduce any complexity in the future when dealing with upgrades, replacements, and general management of Office from a remote stand point. Populate the Company Name with your company information.

2.      Set the Licensing Information and interface during installation. This area also allows you to set the user interface during installation. The default option is to display the full user interface. Other options include completely hidden and a basic interface. The options I typically set for my clients are as follows:

a.       Enter a Product Key

b.      Enable the I accept the terms in the License Agreement

c.       Set the Display level to Basic.

d.      Clear the checkbox on Completion Notice.

e.       Enable the option for No Cancel.

Additional options can be applied as necessary. These will need to be set according to your specific environment needs. Once complete click on File > Save As and save the new MSP file in the location where your Office installation files are stored. If you have multiple MSP files to create you can create a folder called Customizations and store them here. They can each be called when needed from installation scripts.

Here’s a thought for our installation. Wouldn’t it be nice if you could include Service Pack 1 for Office 2010 and any updates released since Service Pack 1 in this installation? Just think how much time that would save by having all of these updates installed right with the product. You could install Office 2010, have it service packed, and updated to the latest security updates all in one shot and with no intervention. “Brian, how is this possible!?” you ask. Well, I’ll tell you. There is a folder called Updates in the sources files location you copied. Simply place all MSP update files in this directory. All MSP files will automatically be executed during the installation and performed silently.

To do this you must first download and extract the Office 2010 Service Pack 1. It can be located here - http://www.microsoft.com/download/en/details.aspx?id=26622 for the 32-bit edition and here - http://www.microsoft.com/download/en/details.aspx?id=26617 for the 64-bit edition. The 64-bit edition is only for 64-bit editions of Office 2010. Keep in mind just because you may have a 64-bit edition of Windows does not mean automatically mean you have a 64-bit edition of Office. Know your software.
After your service pack has been downloaded, simply extract the contents and copy them to your Updates folder. To extract the service pack perform the following steps.

1.      Download the service pack and save it somewhere on your computer. Make sure to remember you saved it.

2.      Go to the Run command and type in the following command
C:\Office2010SP1.exe /extract:C:\OfficeSP1x86
Substitute your file name and extract path to match your environment needs

3.      After the extraction is completed move the extracted files to the Updates folder of your Office 2010 Installation source location

4.      Done!

You can perform this same process for any other updates that need to be applied to the Microsoft Office 2010 installation. Simply download the necessary updates, extract them, and save the contents to the Updates folder. You do not need to create subfolders within the Updates folder. Just copy them into place. They will automatically be executed during the installation.

Let’s recap where we are in the process. We have copied our source files to a network location, we have created a customized MSP file for a silent deployment, and now we have included Service Pack 1 and any other updates we want to execute during installation. It looks like we have a fully functional installation source that meets our needs. Now we get to look at deployment methods. I have written an article in the past about software installation best practices in four major steps. If you have not read this before, take an opportunity to do so now.

Now we can talk about our deployment script. If you have a deployment tool of some sort in your network, I recommend taking full advantage of it. If not, this section will be helpful to you. The steps I am about to provide will prevent the need to walk from desk to desk installing software.

***************************BEGIN SCRIPT*****************************

setlocal

REM *********************************************************************

REM Environment customization begins here. Modify variables below.

REM *********************************************************************

REM Get ProductName from the Office product's core Setup.xml file, and then add "office14." as a prefix.

set ProductName=Office14.PROPLUS

REM Set DeployServer to a network-accessible location containing the Office source files.

set DeployServer=\\SERVER1\Office2010

REM Set AdminFile to the custom MSP file to be used for deployment (required)

set AdminFile=\\SERVER1\Office2010\Customizations\MyCustomDeployment.MSP

REM Set LogLocation to a central directory to collect log files.

set LogLocation=\\SERVER1\Office2010\LogFiles

REM *********************************************************************

REM Deployment code begins here. Do not modify anything below this line.

REM *********************************************************************

IF NOT "%ProgramFiles(x86)%"=="" (goto ARP64) else (goto ARP86)

REM Operating system is X64. Check for 32 bit Office in emulated Wow6432 uninstall key

:ARP64

reg query HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432NODE\Microsoft\Windows\CurrentVersion\Uninstall\%ProductName%

if NOT %errorlevel%==1 (goto End)

REM Check for 32 and 64 bit versions of Office 2010 in regular uninstall key.(Office 64bit would also appear here on a 64bit OS)

:ARP86

reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\%ProductName%

if %errorlevel%==1 (goto DeployOffice) else (goto End)

REM If 1 returned, the product was not found. Run setup here.

:DeployOffice

start /wait %DeployServer%\setup.exe /adminfile %ConfigFile%

echo %date% %time% Setup ended with error code %errorlevel%. >> %LogLocation%\%computername%.txt

REM If 0 or other was returned, the product was found or another error occurred. Do nothing.

:End

Endlocal

************************************END SCRIPT*****************************

This script can be utilized in a GPO as a startup or shutdown script. That way Office can installed at the computer startup or computer shutdown. You may need to make modifications in the script to match your environment.

This should be enough information for now to get started in identifying your needs for deploying Office 2010 in your own networked environment. If you require assistance or have questions about this process, please post a comment. I will be monitoring these regularly and can provide assistance when possible.

Be on the lookout for a future article on deploying Adobe Acrobat products and customizing the deployment options.

The System Administrator's Guide to Software Deployment

This is a teaser for what is to come. I am working a post that will provide some expert information about deploying Office 2010 in a network environment. I expect that to be posted this week. For now, I am going to discuss some software installation best practices that I have found to be beneficial and implemented with my customers.

There are four major steps in software deployment in a networked environment.

Step 1: Know the installation options available for your software. Take the time to learn the deployment options. Visit the manufacturer's web site, read the support documentation, and even look in the included documentation with the software. Sometimes you can even run the setup application with a /? to get installation help. Make sure you have the tools or capabilities to deploy the application with the least amount of administrative effort. Many times all you need is a little ingenuity and the ability to write a script. If I just scared you, don't worry. Scripting is not as scary as it sounds. There's plenty of help out there to get you what you need so you don't have to re-invent the wheel.

Step 2: Know your targets. When deploying software it's not a good idea to just throw spaghetti against the wall and see what sticks. A piece of software can break another piece of software causing what I like to term as a CLM - Career Limiting Move. In a worst case scenario that type of approach could break a piece of software that would be required for the company to make money. If you bring down the company's ability to make money that is what I like to term as a CEM - Career Ending move. You need to find a way to install the software only to the computers that need it. You could use a script to look for a file that exists that would only exist on computers that need the software. If it's in a department of the company maybe there is an IP range involved. You could use the computer's IP address as an identifier. All of these things can be identified through scripts. Deployment tools make this process much easier. This gives you a way to identify your targets.

Step 3: Test your deployment. After you have identified your installation options and targets, create an installation package and install it to a test computer that mimics your targets. This method gives you an idea if the deployment goes as you expected. Look for errors, review logs, make sure the installed application is functional. If anything did not work as expected, review the cause, fix it, and redeploy it. Continue this process until it deploys the way you want it to.

Step 4: Pilot the deployment with a small group of production computers. Once it's ready, send it to a few of the production computers. Make sure it is still doing what you expected. If it not, go through the troubleshooting process. If so, deploy as you see fit within your environment.

I have used these steps as best practices for software deployment throughout my IT career since 1995. I have heard a lot of system administrators tell me they don't have time to work through these processes, because their bosses are wanting the software deployed as fast as possible. This process is not just a CYA process, but a business process, too. These steps reduce the risk to the business by reducing downtime due to failed application deployments. It makes your time more effectively used to be proactively managing your network. All of these efforts translate into bottom line improvements. I bet your boss will like to hear that information. Hopefully, this will help you be a more effective system administrator and provide more value to your career.