The process is broken down into three steps:

1. A minor schema change
2. Loading the picture into Active Directory
3. Updating the Offline Address Book

Click here to read the original article…

Outlook blocked access to the following potentially unsafe attachments: []

Of course the kneejerk reaction is to just rename the extension and resend the email.  While this works the majority of the time, it requires extra steps, time and some forethought before sending the email (while increasing your mailbox size).  A more permanent solution (albeit more dangerous) is to modify the Outlook policy itself either through a registry edit or using a GPO.

Other and more preferred options include:

1. Use a file share or FTP site to save and access the attachment.  This is a Messaging administrator’s dream as it takes the burden off the Exchange servers and places it solely onto the file server.  While message storage is usually at a premium, file share storage can be much cheaper.
2. Use a file compression utility to change the file name extension.  This works great and often saves valuable mailbox space in the process.  Two birds with one stone.

Searching the Internet on this topic brings up many posts (this is not an new topic), and while most seem to be focused solely on how to modify the behavior at the client level, I’ve included some links that the administrator can utilize to adjust the attachment filtering behavior at the server level.
 

Background

For more information on Outlook’s attachment filtering behavior along with a table of all those extensions that Outlook (aka: Microsoft) deems unsafe following this link.

Outlook divides attachments into three groups based on their file name extension or file type.  Outlook handles each group in a specific way.

Level 1

The unsafe category represents any file name extension that may have script or code associated with it. You cannot open any attachment that has an unsafe file name extension.

Level 2

Level 2 files are not unsafe. However, they do require more security than other attachments. When you receive a Level 2 attachment, Outlook prompts you to save the attachment to a disk. You cannot open the attachment in the e-mail message.

Other

When you try to open an attachment that has a file name extension other than those in the Level 1 or the Level 2 list, Outlook prompts you to either open the file directly or save it to a disk.You can turn off future prompts for that file name extension if you clear the Always ask before opening this type of file check box.
 

Customizing Attachment Filtering

So now that you understand a bit more about why let’s focus on the how.  There are a couple of options for customizing attachment filtering behavior.  While this article’s language is specific to understanding and modifying the behavior of Outlook, I’ve also included some options for modifying the attachment filtering features at the server level.

Configure the behavior at the server level

• Use a GPO
  1. Click here for more information on planning for configuring security setting in Outlook
  2. Information for administrators about e-mail security settings in Outlook 2007
• Outlook Web Access
  1. Exchange 2007
  2. Exchange 2010
• Modify the Edge or Hub Transport server (Anti-Spam agents enabled)
  1. Exchange 2007
  2. Exchange 2010

Configure the behavior at the client level

• Edit the registry

Review the MS Exchange Team’s for more information…

Overview

Microsoft Exchange Server 2010 introduces the Exchange Deployment Assistant or ExDeploy, a new Web-based tool that can help you with your Exchange deployment. ExDeploy asks you a few questions about your current environment and then generates a custom checklist and procedures that help simplify your deployment.

You can use ExDeploy for the following scenarios:

• Upgrade from Exchange Server 2003
• Upgrade from Exchange 2007
• Upgrade from mixed Exchange 2003 and Exchange Server 2007
• New installation of Exchange 2010

To access ExDeploy, see Exchange Server 2010 Deployment Assistant.

As you know, Exchange 2010 became generally available last November.  Unfortunately, the GA version had several issues which prevented Unity Unified Messaging interoperability. Cisco and Microsoft together have identified these issues and as of mid-December Microsoft has delivered an updated version of MAPI addressing the primary issues. Cisco is now working aggressively to validate the new MAPI version as well as make the necessary changes in Unity to support Exchange 2010 as follows:

Unity 7.X – March 31, 2010

Unity 5.X – May 31, 2010

Unity 8.X – June 30, 2010

We urge Unity 4.X Unified Messaging customers who plan to upgrade to Exchange 2010 to first upgrade to Unity 7.X once the ES is available in preparation for their upgrade to Exchange 2010.

As for Meeting Place, unfortunately planned support for Office (Outlook) 2010 has been pushed back to MP 8.5, which is not even officially announced at this point.  It’s possible this could be supported in a later version of 8.0 once that has been released, but for 6.0 and 7.0 there is nothing planned.

Customers should ultimately be working with their Cisco representative if they are considering Exchange 2010 soon, but this will at least provide some ideas when Unity support is expected.

Get the version, build and service pack level of Exchange.

NOTE: Click here to determine the version for Exchange 2010…

Step 2

Review this link for a complete limiting of build numbers and release dates for Exchange.

To get detailed information on Exchange 2007 platforms, editions and versions including Rollup information follow this link…

Click here to download…

Want a good way to access ALL the control panel options in Windows 7 in one easy location?  Simply make a folder on your desktop and rename it GodMode.{ED7BA470-8E54-465E-825C-99712043E01C} and you are all set.

Here is what your folder will look like after you rename it:

FYI: I’ve heard that the trick will work in Vista x32 but not Vista x64.

Here is what GodMode will look like:

So no more applying updates one at a time.  The new installer applies all updates for the appropriate server role in one click.

Click here for the October updates…

Here is one fix that I am particularly looking forward too.

975894 Event ID 44031 for trusted domains is logged frequently in Office Communications Server 2007 R2.

As part of the integration of OCS 2007 R2 with Exchange Unified Messaging, OCS 2007 R2 tries to obtain a list of the Exchange Unified Messaging dial plans and servers from all trusted domains. In this scenario, if a trusted domain cannot be reached or if the trust direction for a trusted domain is incoming only, OCS 2007 R2 cannot obtain the list from that domain. Event ID 44031 is logged in the event log for each such domain.

MS09-056: Vulnerabilities in CryptoAPI could allow spoofing

This security bulletin (KB974571) has been updated with a Known Issues section and FIX for OCS 2007 R2/ RTM, LCS 2005 / SP1 and Office Communicator 2007 / 2005.

Event Type: Error
Event Source: OCS Server
Event Categeory: (1000)
Event ID: 12290
Description:
The evaluation period for Microsoft Office Communications Server 2007 R2 has expired.  Please upgrade from the evaluation version to the full released version of the product.

 
WHAT?  Are you kidding me?  So I did some digging on the Internet and quickly came across Doug’s post.  He discovered that KB974571 is causing OCS/LCS servers to believe that they are running an evaluation version and have expired which in turn causes the services to shut down.
 
Until this patch is fixed I HIGHLY recommend that you delay the install of KB974571.

Click here for Doug’s post…

The IM Notification Agent on the Access Edge is failing with the following Application Log events:

Event ID: 10162
Type: Error
Source: ForefrontNotificationAgent
Description:
“ERROR: Microsoft.FSO.IMClient.dll.IMClient.RaiseLoginDone(“<System.Boolean success><System.String message>”) – Error occured logging in to server: 80072746: .”

AND

Event ID: 10161
Type: Error
Source: ForefrontNotificationAgent
Description:
“ERROR: ForefrontNotificationAgent.exe.NotificationAgent.imClient_LoginDone(“<System.Object sender><FSOIMClient.ReportSuccessEventArgs e>”) – Failed to login.”

More information

You have correctly setup the IM Notification Agent account per the instructions found here on TechNet for an Access Edge server.  You have verified the notification account id and password are accurate by logging in with the notification account from a remote client. Your IM Notification Agent settings look as follows:

IM Notification Agent settings

Use ForefrontRTCProxy Service Credentials: Unchecked
Transport: TLS
Username: domain\userid
Password: *****
SIP URI: sip:userid@company.com
Home or Pool Server: Director FQDN

SIP Logging on the director server shows a “SIP/2.0 301 Redirect request to Home Server” message with no response from the home pool.  This tells us that the Director server is treating the Forefront Notification Agent as an inside client and thus is trying to redirect the “client” to the notification account’s home pool.  The Director server should proxy the request, not redirect.  Remote user connections cannot be redirected.  Read here for more information on how a director behaves with internal vs. external clients. Changing the Home or Pool server settings to point to the notification account’s home pool FQDN does not solve the problem.

Resolution

Option 1

In the Home or Pool Server field add the FQDN entry for Access Edge external interface (sip.company.com).  However just changing the entry is not enough, you’ll also want to specify the port as follows “sip.company.com:443”.  This is of course assuming that your AE external interface FQDN is sip.company.com.  Make sure the Access Edge server correctly identifies the external FQDN to the correct IP address.  Changing to the AE FQDN will route the Forefront Notification Agent login request through the Access Edge service and then to the next hop server (Director).  The Director will then properly process the login request as a remote client.

Further SIP logging on the Director reveals a successful “Routed a request on behalf of an application” followed by a successful response from the account’s home pool.

IM Notification Agent settings

Use ForefrontRTCProxy Service Credentials: Unchecked
Transport: TLS
Username: domain\userid
Password: *****
SIP URI: sip:userid@company.com
Home or Pool Server: sip.company.com:443

Option 2

Another recent fix that was brought to my attention was to enter the SIP URI without the “sip:” prefix.  Your settings would be as follows:

IM Notification Agent settings

Use ForefrontRTCProxy Service Credentials: Unchecked
Transport: TLS
Username: domain\userid
Password: *****
SIP URI: userid@company.com (without sip: prefix)
Home or Pool Server: sip.company.com:443

Cause

As for the cause, I cannot speak to what is specifically causing this issue as I feel this is either a bug in the Forefront notification agent OR an error in the documentation.