E-mail authentication built on the Sender ID Framework (SIDF) is gaining wide adoption, providing a major advancement in the fight against spam and phishing messages. In fact, more than a third of the world’s e-mail volume is already authenticated and SIDF-compliant. Using Send ID as well as other anti-spam features in Exchange Server 2007 can effectively protect customers from spam attacks and save on the total cost of operation. Here’s how it works and how to configure SIDF in Exchange Server 2007.

Exchange Server 2007: Fighting Spam and Phishing with Sender ID
http://www.microsoft.com/technet/technetmag/issues/2006/12/sidf/default.aspx

Known Issues and Resolutions

Known issues and resolutions
Problem	Resolution
Unable to install some ActiveX controls in Internet Explorer	Launch Internet Explorer elevated by clicking the Start button, and then pointing to All Programs. Right-click Internet Explorer and select Run as administrator. Next, perform the ActiveX installation. Exit this instance of Internet Explorer and start a new instance running as a standard user to continue.
Non-administrator users cannot create files on the system root drive, for example, c:\	By default, Windows Vista redirects any writes to protected areas (E.G. C:\ and C:\%systemroot%) to the currently logged-on user's profile. Resolution: • Create files and folders in the user’s profile (under \users\(user) or \users\public). OR • Right-click Command Prompt and select Run as administrator. Create the directory from the elevated command window.
Setup detection may not detect all setups	Run the setup.exe elevated. See the section Marking an Application that Requires a Full Administrator Access Token.
No elevation prompts from command windows	Launch the program by clicking the Start button and then pointing to Run.
Unable to run an .msi file to install an add-in for Visio 2007	1. Open the .msi file in an MSI editor. For example, use the Orca MSI Editor that is provided in the Microsoft Windows Software Development Kit (SDK).   For more information about the Windows SDK, visit the following Microsoft Web site: http://msdn2.microsoft.com/en-us/library/aa370834.aspx  2.  Open the .msi file in the MSI editor.  3.  Locate the Custom Action table.  4.  Locate the VisSolPublish_BumpVisioChangeId custom action, and then change the type to 3622.  5.  Save and then close the .msi file.
Error message “Hook cannot be created” is received while running .Net Framework 1.1-based applications	Install hot fix in article 925168
The "Add" and "Remove" commands on the Drivers tab are unavailable on a remote Windows Vista-based print server	1.  Click Start , type regedit in the Start Search box, and then click regedit in the Programs list.  If you are prompted for an administrator password or confirmation, type your password or click Continue.  2.  Expand the following subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies  3.  Click System, right-click LocalAccountTokenFilterPolicy, and then click Modify.  4.  In the Value data box, type 1 , and then click OK.

After we understand how UAC works and realize the importance of enabling UAC to prevent potential problems that may arise during your Windows Vista deployment in
your environment, we can move on to discussing how to configure UAC to optimize 
security and ease of use. The consent UI behavior as well as some other UAC 
features can be changed by group policy for administrators. 

This section details the main method for configuring UAC by Administering 
UAC with the local Security Policy Editor and Group Policy. 
For administrators in a domain environment, they can configure UAC 
settings in domain security policy.

1.    Click Start, click All Programs, click Accessories, click Run, type secpol.msc in the Open text box, and then click OK.

2.    From the Local Security Settings console tree, click Local Policies, and then Security Options.

3.    Scroll down and double-click corresponding UAC policy settings to configure

4.    Close the Local Security Settings window.

There are in total eight Group Policy Object (GPO) settings that can be configured for UAC. The following list includes the policy settings:

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

User Account Control: Behavior of the elevation prompt for standard users

User Account Control: Detect application installations and prompt for elevation

User Account Control: Only elevate executables that are signed and validated

User Account Control: Run all administrators in Admin Approval Mode

User Account Control: Switch to the secure desktop when prompting for elevation

User Account Control: Virtualize file and registry write failures to per-user locations

User Account Control: Admin Approval Mode for the Built-in Administrator account

User Account Control: Only elevate UIAccess applications that are installed in secure locations

Hereby we outline three common tasks that administrators perform during the set up and configuration of client computers running Windows Vista. The following policies brief the tasks of disabling Admin Approval Mode, disabling UAC from prompting for credentials to install applications, and changing the elevation prompt behavior.

 1. Disable Admin Approval Mode

Policy Item: User Account Control: Run all administrators in Admin Approval Mode.

Default Value: Enabled
Description: There are two possible values:

• Enabled - Both administrators and standard users will be prompted when attempting to perform administrative operations. The prompt style is dependent on policy.

• Disabled - UAC is essentially "turned off" and the AIS service is disabled from automatically starting. The Windows Security Center will also notify the logged on user that the overall security of the operating system has been reduced and will give the user the ability to self- enable UAC.

Note: Changing this setting will require a system reboot.

 2. Disable User Account Control from prompting for credentials to install applications

Policy Item: User Account Control: Detect application installations and prompt for elevation.

Default Value: Home: Enabled. Enterprise: Disabled
Description: There are two possible values:

• Enabled - The user is prompted for consent or credentials when Windows Vista detects an installer.

• Disabled - Application installations will silently fail or fail in a non-deterministic manner. Enterprises running standard users desktops that leverage delegated installation technologies like GPSI or SMS will disable this feature. In this case, installer detection is unnecessary and therefore not required.

 3. Change the elevation prompt behavior

 Policy Item: User Account Control: Behavior of the elevation prompt for administrators.

Default Value: Prompt for consent
Description: There are three possible values:

• No prompt – The elevation occurs automatically and silently. This option allows an administrator in Admin Approval Mode to perform an operation that requires elevation without consent or credentials. Note: this scenario should only be used in the most constrained environments and is NOT recommended.

• Prompt for consent – An operation that requires a full administrator access token will prompt the administrator in Admin Approval Mode to select either Continue or Cancel. If the administrator clicks Continue, the operation will continue with their highest available privilege.

• Prompt for credentials – An operation that requires a full administrator access token will prompt an administrator in Admin Approval Mode to enter an administrator user name and password. If the user enters valid credentials, the operation will continue with the applicable privilege.

Policy Item: User Account Control: Behavior of the elevation prompt for standard users

Default Value: Home: Prompt for credentials. Enterprise: No prompt
Description: There are two possible values:

• No prompt – No elevation prompt is presented and the user cannot perform administrative tasks without using Run as administrator or by logging on with an administrator account. Most enterprises running desktops as standard user will configure the “No prompt” policy to reduce help desk calls.

• Prompt for credentials – An operation that requires a full administrator access token will prompt the user to enter an administrative user name and password. If the user enters valid credentials the operation will continue with the applicable privilege.

For more information on how to configure UAC via policy, view the following links:

How to use User Account Control (UAC) in Windows Vista

http://support.microsoft.com/?id=922708

http://technet.microsoft.com/en-us/windowsvista/aa905117.aspx

Can a popup put you in prison?

You love it, you hate it....ok, you may hate it, but....

You’ve seen it, or at least heard about it in Windows Vista: User Account Control or UAC (formerly known as LUA or Least Privileged User Account). With the release of Windows Vista, we hope that more and more ‘cyberholics’ will better appreciate this new feature.

There has been tons of speculation, concern and anxiety around how UAC will impact troubleshooting and workflow so I want to be sure everyone understands the basics and knows where to get more information. Much of this will be obtained in a well constructed UAC technical documentation released on the Microsoft TechNet portal. We would also like to recommend you read the Tim Sprinston’s blog, which provide unique perspective to have a good understanding to UAC:

http://blogs.technet.com/ad/archive/2007/01/29/i-ll-say-it-again-user-account-control.aspx.

Here is some data that you should keep in mind before deciding to turn UAC off!

• UAC has the potential to reduce the operating system attack surface by 85%!
• UAC goes through 3 checks for applications (in this order):

• Interactive Users - All interactive users (except the built-in Administrator) will be affected.   They will need to provide consent UI before running any application or task with administrative privileged. 
• Services, System Components, Built-in Administrator - Services, system components and the built-in administrator will not be impacted. However, changes may be needed to applications and tasks that manage components by marking these to require administrative privileges. 
• Built-in Administrator account is now disabled by default on new installs of Windows Vista (more information available @ http://blogs.msdn.com/windowsvistasecurity).

RMS 1.0 SP2 added native support for SharePoint Server 2007. For a step-by-step guide about deploying RMS with SharePoint Server 2007, please refer to this document:

http://www.microsoft.com/downloads/details.aspx?FamilyID=7bab2321-71e6-4cf2-8bcd-0880e0d1cda3&DisplayLang=en