Wednesday, July 27, 2005

Enabling and disabling MAPI and/or non-Cached access per user in Exchange 2003 SP2

Exchange Server 2003 Service Pack 2 (SP2) adds functionality to allow the administrator to completely turn off MAPI access for a given user or grant access to a user whose Outlook is configured for cached mode but deny access otherwise. This functionality is expected to be valuable to providers of hosting services that for example want their end users to connect to Exchange with Outlook Web Access but not with Outlook (via regular MAPI connection or RPC over HTTP). 

The ProtocolSettings attribute on the user object in the Active Directory stores client access settings. This attribute is a multi-valued string property, where each string applies to a different protocol. MAPI access can be restricted by manually adding the following string to the ProtocolSettings attribute using a tool such as ADSIEdit:

 

MAPI§<Bool1>§<Bool2>§§§§§§

 

The eight § separators define exactly nine fields. The meanings of the fields are as follows:

 

MAPI

Specifies that this string contains settings that apply to the MAPI protocol

Bool1

0 to block all MAPI access; 1 to determine MAPI access based on Bool2.

Bool2

0 for “no effect”; 1 to deny access to non-cached mode Outlook clients

Remaining 6 fields

Currently not used

 

If there is no MAPI string in ProtocolSettings, all MAPI clients are allowed.

 

Some examples of this:

 

MAPI§0§<Bool2>§§§§§§- this would block ANY client MAPI access to the mailbox (cached or not), no matter what the value of “Bool2” was.

 

MAPI§1§0§§§§§§- this would not block anything, because the value “Bool2” is set to “0”. MAPI access is allowed for online and cached clients.

 

MAPI§1§1§§§§§§- this would block any “online” (non-cached) MAPI access. Outlook clients accessing the server using cached mode would be able to connect to the mailbox.

 

If the MAPI string does not have the eight separators and conforms to the expected data types, the behavior is undefined.

 

The access restrictions specified above do NOT apply in the following cases:

- the client is an Exchange component (for example, mailbox moves would still work correctly regardless of the MAPI access settings for the mailboxes)

- the client is doing delegate access to the mailbox

 

Delays in ProtocolSettings becoming effective can be caused by:

 

1. As with others mailbox properties stored in the DS, ProtocolSettings are cached in the MBICache (default TTL = 2hrs) and in DSAccess (default TTL = 15 min). These caches may delay the time it takes for a change in the ProtocolSettings to become effective.

 

In order to read more about the Information Store cache, please see the following article:

 

179065 XADM: Changes to Primary Windows NT Account on Mailbox Do Not Take Effect

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

 

2. The access check is performed at connection time. If a user is connected and the setting is changed to deny access, the change won’t take effect until the client disconnects (which may take place several days later).

 

3. In the case above, since Outlook typically uses more than one connection, if one connection drops while the others stay on, there may be unexpected behavior when Outlook tries to re-establish the dropped connection. This client has will be denied access and all it takes to find out what is happening is to restart Outlook.

 

One additional thing to mention is that is the following registry key is set:

 

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Disable MAPI Clients

 

is set to block certain client versions server-wide, specific users could be affected (blocked) either by the above registry setting or the per-user MAPI ProtocolSettings.

 

Tuesday, July 26, 2005

How to export the members of a distribution group in Exchange 2000/2003 using LDIFDE.

 Export distribution group members using LDIFDE

These steps outline how to export the members of any distribution group from Active Directory using LDIFDE.  The syntax required
looks like this:
 
ldifde -f export.ldf -d "cn=\distribution group DN" -l member -s server
 
-f     specifies the file name to save the data to.
-d    specifies the RootDN (basically where the search starts).
-l     specifies what parameter you are interested in (in this case we are looking at the 'member' attribute.)
-s    specifies which Active Directory Domain Controller to use.
 
The distribution group DN (Distinguished Name) consists of the following:
 
     1. Distribution Group name
     2. OU that the Distribution Group resides in
     3. NetBIOS domain name
     4. Top level domain which domain resides in (usually 'com' but not always)
 
As an example, to export the members of a Distribution Group named 'Partners' in the 'Users' OU, you would use the following
syntax against the domain controller DC01 in the Microsoft.com domain:
 
ldifde -f export.ldf -d "cn=\Partners,ou=users,dc=microsoft,dc=com" -l member -s DC01
 
Your output would look like this:
 
dn: CN=\PARTNERS,OU=USERS,DC=MICROSOFT,DC=com
changetype: add
member: CN=Smith\, Bob,OU=Users,DC=microsoft,DC=com
member: CN=Smith\, Glen,OU=Users,DC=microsoft,DC=com
 
You could then take this output and view it with notepad or import it in to Excel for manipulation.  This is just one of the many
uses of ldifde.  The full syntax of the command can be viewed by typing 'ldifde' at a command prompt.  As always, fully
understand the impact of your syntax before running it against a production Active Directory.

Configuring Exchange SMTP Gateways at Microsoft

Here is an article on how Microsoft configures their SMTP gateway services under E2K3.  Basically, they create at least two SMTP Virtual Servers on gateway servers so they can control the SMTP filtering on inbound, while unrestricting outbound.  It is not recommended to do this on mailbox servers however.

"Description of how Microsoft IT custom configures its SMTP servers to make its mail flow more securely and manageably."

Monday, July 25, 2005

Clustered Exchange Nodes as AD domain controllers

Evan Dodd posted this follow-up post on clustering with E2K3 and AD on the same servers.  Bottom line, don't do it.  ;-)

"I blogged about KB.898364 briefly when it was created, but over this past weekend there was a flurry of newsgroup posts about putting clustered Exchange onto cluster nodes that are also domain controllers. Several responses referenced KB.281662 (how to cluster AD domain controllers), which didn’t very clearly specify not to do this with Exchange.

That’s been rectified. The More Information section of KB.281662 now clearly states that Exchange is not supported on cluster nodes which are configured as domain controllers:

Note Exchange 2000 and Exchange Server 2003 are not supported in a clustered configuration where the cluster nodes are domain controllers.

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

898634(http://support.microsoft.com/kb/898634/) Active Directory domain controllers are not supported as Exchange Server cluster nodes

Hope it helps!"

Tuesday, July 19, 2005

Whitepaper: Exchange Server Error-1018

Here is a good Microsoft updated Whitepaper on what causes 1018 database errors and how to recover from them.  A MUST read for any admin!  "Detailed discussion of the conditions that result in error -1018. It also covers the detection mechanisms that Exchange uses to discover and recover from damage to its database files."

Monday, July 18, 2005

Exchange 2003 Server Service Pack 2 (SP2) Anti-Spam Framework

Here is a fantastic post by Alexander Nikolayev on the Anti-SPAM framework that is slated for E2K3 SP2...

"Spam is our e-mail customers' No. 1 complaint today, and Microsoft is innovating on many different fronts to eradicate it" - Bill Gates.

With the release of Exchange 2003 Server SP2 Microsoft and the Exchange Server Product Unit are taking another big step in helping alleviate the Unsolicited Commercial Email (spam) problem.  Announced a year ago, the Coordinated Spam Reduction Initiative clearly outlined the plan for drastically reducing the amount of spam customers may experience through the introduction of new technology solutions.  A year later, Exchange 2003 SP2 delivers exactly that - new technology that significantly helps combat spam.

With the introduction of Exchange 2003 Server, Microsoft built a framework that included a number of features intended to reduce the volume of spam.  The framework called for a solution based on a multi-layered approach around the idea that most if not all spam should be stopped at the gateway, and before reaching the final recipient's mailbox.  The adoption of this approach has proven to be very successful and highly effective, and with the release of SP2 the framework will be refined even further to include the following steps of which I'll summarize below:

1. Connection Filtering
2. SMTP Filtering
3. Content Filtering
4. Inbound mail processing rules

This is an example of typical mailflow:

At a point during mail transmission from the origination point to the final destination (recipient), a mail item enters the Exchange organization.  There it goes through the extensive anti-spam processing framework and the following anti-spam layers:

Layer 1 - Connection Filtering

The first step in spam verification process is to establish an understanding where the mail is coming from.  Highly effective, this method accounts for roughly 25% of all blocked mail inside of Microsoft Corporation.  Exchange 2003 Server SP2 provides the following framework to achieve this functionality:

1. Support for multiple Real Time Block List (also known as DNS Block List) providers (including paid subscriptions)
2. Customized rule-based Block List service configuration
3. Custom-tailored server response (DSN) based on provider and connection initiation source (i.e. open relay, known source of spam)
4. Global Accept and Deny Lists
5. Configurable exception list that override the block list

If enabled, Connection Filtering will snap the IP address on the incoming connection from the winsock and send a DNS query to verify whether the connecting identity has been listed as an open relay or if it is a known source of spam.  If the returned DNS query contains the connecting IP address on the DNS block list, Connection Filtering will close the connection down and trigger a customized server response back to the sender.  If the sender was legitimate and got onto the block list by mistake, s/he can implement corrective actions based on the custom NDR received.  Connection Filtering also allows the remote user from the blocked IP to submit mail to the postmaster or administrator of the Exchange organization for implementing corrective actions if the sending identity was put on the block list in error.  Connection Filtering is very useful as it is capable of defending Exchange deployments from spam without generating additional resource consumption (CPU cycles, further load on the downstream servers, extra mail processing and NDR handling, etc.).  Exchange 2003 Server can also perform reverse DNS lookup on incoming messages to resolve originating IP to a host name through the DNS.

The majority of Exchange 2003 Servers have been deployed behind the perimeter and do not face the Internet directly.  This renders Connection Filtering less useful as the feature relies on getting the original sender's IP to run the DNS query on.

With the release of SP2 this deficiency has been addressed by introducing a new headers parsing algorithm for originating IP retrieval.  Now, Exchange 2003 Server SP2 with Connection Filter deployed can be positioned anywhere in the organization and perform filtering as it would on the perimeter. 

Layer 2 - SMTP Filtering

If the incoming connection passed through the Connection Filtering layer, the next in line is SMTP Filtering.  Exchange 2003 Server SP2 makes extensive use of SMTP protocol filtering and this feature contributes to 35% of all blocked messages in Microsoft Corporation (MSIT department).  SMTP Filtering has been implemented to monitor live SMTP sessions and functions as a real-time filter.

SMTP Filtering has been complemented by comprehensive SMTP session RFC compliance enforcement and starts with the first RFC2821 HELO/EHLO command.  The SMTP implementation in Exchange 2003 Server SP2 will monitor and examine the session for potential violations and will not accept mail when the sending identity does not conform to or severely violates SMTP governing RFCs.  I.e. no mail transaction will be allowed if the remote party does not begin the SMTP session with an appropriately constructed greeting that contains an RFC2821 compliant domain part.  Similarly, RFC compliance will be enforced on MAIL FROM: and RCPT TO: commands to ensure that malicious users can not get around SMTP Filtering by providing, for example, 8-bit characters in the RFC2821 stream.  Another common tactic deployed by spam senders is to confuse anti-spam solutions by changing the order of commands in an SMTP session.  Exchange 2003 SP2 enforces RFC compliance in this area, preventing spam senders from executing an attack this way.

To prevent dictionary attacks and valid e-mail address harvesting, Exchange 2003 Server SP2 will respond to the VRFY command, but will not release the directory information to the remote party.  Exchange 2003 Server SP2 by default does not support the EXPN command.

SMTP Filtering is based on rules configured by the administrator and consists of Sender Filtering and Recipient Filtering.  Sender Filtering starts with the first RFC2821 MAIL FROM: command.

Sender Filtering:

1. Sender Filtering allows a list of senders to be specified that are prohibited from sending messages to a particular Exchange organization. 
2. Sender Filtering can be easily configured to reject messages originating from certain domains or email addresses. 
3. Sender Filtering filters messages with blank sender information and provides a mechanism for spoof detection (e.g. if the message coming from outside the organization claims to be sent from the CEO of organization where Exchange is deployed). 
4. Based on the administrator-configurable actions the filter can drop the incoming connection if the Sender's address matches the filter.
5. To minimize information disclosure to malicious users, Sender Filtering can silently accept mail and delete it without notifying the sender.
6. Sender Filtering provides an option for archiving filtered messages for a forensic analysis as needed. 

Once a mail item gets through Sender Filtering it faces  Recipient Filtering.  Recipient Filtering starts with the first RFC2821 RCPT TO: command.

Recipient Filtering:

1. Recipient Filtering enables inbound mail filtering for a particular recipient in the Exchange organization. 
2. Recipient Filtering supports blocking mail based on wildcards.  This enables administrators to use patterns to block entire ranges of recipients.
3. Recipient Filtering filters messages sent to non-existent recipients, rejecting them at the protocol level.  By rejecting non- existent recipients at the protocol level (on RFC2821 RCPT TO: command), the Exchange server is protected from doing expensive NDR generation work and clogging the Badmail directory.

4. Enabling filtering of the Recipients who are not in the Directory potentially allows spam senders to discover internal directory information (valid e-mail addresses in the Exchange organization).  A malicious user can execute address book mining by monitoring/parsing the server responses to RCPT TO: commands.  To mitigate this threat Exchange 2003 Server SP2 supports SMTP command tarpitting.  An administrator can configure Exchange to implement an n-seconds delay of the server response to the RCPT TO: command if a DHA attack is encountered or if the remote party violates SMTP RFC conformance.  When a malicious user tries to harvest responses the Exchange server significantly slows down its responses (to an admin-defined delay interval) and the attack becomes infeasible. 
5. Ability to restrict Distribution List mail submissions to authenticated users only contributes to the Recipient Filtering Framework.
6. Recipient Filtering applies only to anonymous connections so all authenticated identities bypass Recipient Filtering rules. 

Layer 3 - Content Filtering

If a mail item gets through Recipient Filtering it faces Content Filtering.  Content Filtering in Exchange relies on Microsoft Research SmartScreen machine learning technology incorporated into the Intelligent Message Filter (IMF).

Intelligent Message Filter:

Messages from the Internet arrive at the Exchange SMTP gateway and enter the Exchange 2003 Server anti-spam framework. Previous layers of the Exchange 2003 SP2 anti-spam solution (connection, sender and recipient filtering) block message submission before message data is sent.  If a message passes all of these then the message body is received. A custom event sink (msgfilter.dll) is invoked when the SMTP End of Data event occurs. The sink passes the message to the Intelligent Message Filter SmartScreen DLL. The SmartScreen technology determines the Spam Confidence Level (SCL) rating of the message which is returned to the sink for comparison against the gateway SCL threshold. The Administrator defined action is applied if the message SCL is greater than the gateway threshold.  Otherwise, the SCL rating is added to messages for transmission to the recipient's inbox.

As of today, the SmartScreen technology deployed by the Microsoft IT department blocks 40% of remaining messages that passed through the previous anti-spam layers (Connection and SMTP filtering).

Anti-Phishing:

With the introduction of Exchange 2003 Server SP2 Intelligent Message Filter extends the anti-spam functionality to support anti-phishing.  The new SmartScreen anti-phishing technology will impact the SCL ratings and also expose an independent Phishing Confidence Level (PCL) value as an output of the filter.  The new anti-phishing functionality is totally transparent to administors and includes the following features:

1. Anti-phishing heuristics
2. Anti-phishing consistency list
3. Anti-phishing block list
4. Anti-phishing allow list
5. PCL values map to weights within the DAT file that allow for non-deterministic SCL adjustment  

Anti-phishing technology relies on heuristics, the consistency list, and the allow list to detect phishing scams.  These lists are not exposed for administration and are updated during regular IMF updates (frequency of updates will be determined later).  The PCL score is one of the factors that trigger final SCL assignments. 

Custom Message Weight:

Custom Weighting (also known as Bad Words List) is a file-based implementation with no supporting UI.  Within the file specific words/phrases can be added along with their relative text part location (Subject or Body) and their associated modifier value.  The supported modifier values can include positive and negative increments, as well as MAX and MIN values.  During anti-spam mail processing the IMF will look into the file and search inside the mail item for a string/word/phrase match.  If a match is found the weight of the SCL will be adjusted according to the modifier value.  If MAX or MIN values are specified for particular word or phrase, they will move the SCL towards MAX or MIN.  The Custom Message Weight feature allows administrators to custom tailor the filter to account for specific words or phrases and adjust it on the fly to act on particular message content as needed.

Custom Server Response when IMF is configured in 'Reject' mode:

To mitigate False Positives, a problem common to all types of automated anti-spam technologies, IMF can be configured to work in "Reject" mode.  This allows for False Positives investigations if the mail was submitted by a legitimate sender and rejected by the filter.  SP2 allows customization of the server response string that is generated and appended to the NDR sent back to the sender.  The default response "550 5.7.1 Requested action not taken: message refused" can be altered to provide blocked legitimate users with meaningful explanation as to why their message was blocked.  This will alleviate investigation of False Positives and decrease support costs associated with the anti-spam processing.

Sender ID Filtering:

Sender ID is an industry standard framework created to counter e-mail domain spoofing.  Sender ID is aimed at removing the ambiguity associated with the sender identity by verifying that each e-mail message originates from the Internet domain from which it claims to come based on the sending server's IP address. Eliminating domain spoofing will help legitimate senders protect their domain names and reputations, and help recipients more effectively identify and filter junk e-mail and phishing scams.

The steps in the process are:

1. The Sender sends an e-mail message to the Receiver.
2. The Receiver's inbound mail server receives the mail.
3. The Receiver's server checks for the SPF record of the sending domain published in the Domain Name System (DNS) record.
4. The Receiver's e-mail server determines if the sending e-mail server's IP address matches the IP address that is published in the DNS record.

Sender ID defines an algorithm for detecting the email address of the entity that is most recently responsible for injecting a message into the email system by extracting the Purported Responsible Address (PRA). The extraction of the PRA ensures Sender ID verifies the appropriate sender against the correct IP addresses as email systems can legitimately forward mail on behalf of other mail servers.

The Sender ID feature has 3 modes:

1. Delete (silent delete - no NDR generated)
2. Reject (the mail will be rejected at the protocol level)
3. Accept (the mail item will be stamped with the Sender ID result for IMF consumption). 

The first and second mode will delete or reject mail that failed the Sender ID verification (i.e. a clear case of spoofing), the rest of the mail items will be stamped with the Sender ID status and passed along.  The last option will just stamp the Sender ID status onto the mail item (even in the case of spoofing).  This status will be passed to the new Intelligent Message Filter and trigger appropriate Spam Confidence Level (SCL) score modification.

Tuesday, July 12, 2005

July 2005 Update for Outlook 2003 Junk Email Filter (KB895658)

This update provides the Junk E-mail Filter in Microsoft Office Outlook 2003 with a more current definition of which e-mail messages should be considered junk e-mail. This update was released in July 2005.

Download At Source

Description of the Update for Outlook 2003 Junk Email Filter (KB895658).

Can Exchange 2003 be installed on 64-bit editions of Windows Server 2003?

Here is a good post by Nino Bilic on the compatibility of E2K3 (32bit) running on Windows Server 2003 x64. 

It seems like a question of compatibility / incompatibility of current versions of Exchange (mainly Exchange 2003) and Windows Server 2003 x64 editions is coming up more and more, so let’s address it.

 

In short – running current versions of Exchange, including Exchange 2003 on Windows Server 2003 x64 editions is not supported.

 

In fact, Exchange 2003 does not even install properly under WOW64. There are several reasons for this – some are related to Exchange 2003 IIS dependency but the biggest problem is that Exchange Setup installs the IFS (Installable File System) driver (exifs.sys) which is a 32 bit driver. On x64 editions of Windows, all of the Kernel mode components (which includes drivers) have to be native 64 bit components, while the User mode applications can be run under WOW64. This problem can not be addressed in future Exchange 2003 Service Packs either.

 

Now – the future is bright, we have plans, just not with current versions of Exchange. There is a list of applications that will run under Windows Server 2003 x64 in either 32 bit compatible or 64 bit native mode and you can find it here.

 

For more information on Exchange 2003 installation requirements, please go to this page.

 

Monday, July 11, 2005

Microsoft Global Contact Access released for Windows Mobile

Previously available internally inside of Microsoft, now this application is available for everybody to download. If you use MS Exchange at work, now you can use it to look up information wirelessly.

Microsoft Global Contact Access allows you not only to look up contact data about specific people - remotely from Microsoft Exchange server but you can also look up availability of given person, i.e. whether he/she will be busy at given time:

With Microsoft Global Contact Access, you can use Pocket Outlook on your Windows Mobile-based Smartphone or Pocket PC Phone Edition to look up contacts in the Global Address List (GAL) on your corporate Exchange server.

You can also check your co-workers' schedules to see if they're free or busy, and add multiple recipients to a meeting request.

Even if you're away from your office you'll have all the information you need to connect with any co-worker in your organization, and send them e-mail or request a meeting.

To learn more or to download this application for your smartphone or Pocket PC click here.

Exchange Hardening Guide

An updated E2K3 Security Hardening Guide has been posted on the MS website.  Download the Exchange Server 2003 Security Hardening Guide . This guide is designed to provide you with essential information about how to harden your Exchange Server 2003 environment. In addition to practical, hands-on configuration recommendations, this guide includes strategies for combating spam, viruses, and other external threats to your Exchange 2003 messaging system.

Friday, July 08, 2005

Can't run Exdeploy after installing W2k3 SP1?

Here’s an interesting problem: After you apply Windows 2003 SP1, the new security settings prevent running HTA files from a network share. So this means if you download the Exdeploy pack and dump it into a network share, it won’t work properly on a W2k3 SP1 server.

The workaround, of course, is to put the files locally on the W2k3 SP1 server.

Seems to me that people most affected by this should be those who are doing cross-site mailbox moves, since anyone doing a regular in-place upgrade from Exchange 2000–>2003 wouldn’t yet be running the server on Windows 2003 SP1.

See KB.897340 for more info.

Thursday, July 07, 2005

IMF renamed to Junk Mail Filter in SP2; SenderID and Anit-Phishing in EX2k3 SP2

When Exchange 2003 SP2 is released the SPAM filter known as Intelligent Message Filter or IMF will be included in the SP. Also it will be renamed so it matches the name that Outlook 2003 uses.

Another filter that is added in the SP is Sender ID. A myth on Sender ID is, that if you enable it that you won't receive any email from domains that don't have a Sender ID in there DNS record in there DNS zone. This is not the case! Sender ID filter will check if a Sender ID DNS record is present, then it will check if the email that is received from the registerd SMTP server, if this is not the case only then an action will be taken. What action is your choice, reject, delete, nothing. So when there is no Sender ID of the Domain registerd the Sender ID filter ignores it and the email will get through anyway.

Yet another filter is added, the anti phising filter, this filter wont be configurable and therefore won't show up in the UI, just as anti-spam and its SCL-flag (SPAM Confidence Level) now a PCL (Phishing Confidence Level) flag is set to an incoming email, both flags gives Exchange a more granular choice of what to do with the message.

Exchange 2003 Service Pack 2 (SP2) Remote Wipe functionality

Here is some fantastic information on SP2's Remote Wipe functionality from Salman Zafar

Remote Wipe is a new feature in E2K3 SP2 that will enable the Exchange admins to force a device to delete its contents remotely. This can come in very handy when an end user loses their device or if the device is stolen -- and there is a risk that someone could access personal or confidential data. I should point out that there are a number of other policy/security related features in E2K3 SP2 to help mitigate this risk. For example, an Exchange admin can also enforce the user to use a PIN, can enforce a length for the PIN, can enforce whether the PIN is numeric or alphanumeric, and can enforce a specific PIN timeout. This coupled with the local wipe capability -- which removes all data from the device when someone enters an incorrect PIN x number of times provides good risk mitigation when a device is lost of stolen. But, remote wipe is intended to provide an additional layer of security on top of all this.

Remote Wipe UI

There is an ASP.NET administration web page which will allow the admin to view the list of devices for a particular user at which point the admin can send wipe commands for a given user, delete old or unused partnership between devices and users or even cancel the wipe command issued for a particular device for that user.

The web page has a transaction log which can be viewed by any admin that accesses that webpage and it shows a list of all actions taken on a particular user and device partnership containing the Date and Time when the activity took place, the user name, the SMTP address, Device ID, Device Type and the action that was taken (e.g. Cancel Wipe, Delete).

The setup will only work for administrators. IIS6 is required for the install. With IIS5 we have an auth issue with the tool. The way we designed it is we wanted admins to be able to give permissions to other users to access the page if needed. For that requirement we had to use the System account the app pool runs under to do an admin logon to the BE. This works great in IIS 6 since the app pool runs as local system. However, in IIS 5 the settings are to run asp.net WP under IWAM_machinename which is a restricted account.

What gets installed when we run the setup

Once the setup is run, a vdir with the name "MobileAdmin" is created and only Network Service/ASP.NET or administrator have access to it. A directory called "Microsoft Exchange ActiveSync Administration" is also created under Program Files.

Using the MobileAdmin webpage

To view the website we require SSL. This might require a cert to be issued. If that is the case, it will be issued automatically. To view the webpage type

            https://<ServerName>/MobileAdmin

Note: since we require SSL you have to use HTTPS. If you use HTTP, you will get the following error message "The page must be viewed over a secure channel"

Once you enter the URL using https you might get the following security alert asking you if you want to install the cert if you don't have one already.

Note: You might or might not see this depending on if you need the cert to be installed or not.

At this time, either the admin or those users who have permission to view this page will be able to view the main page. The admin will be required to enter their credentials before proceeding.

To give a user permission to access this page you can either go to IIS Manager. Right click on MobileAdmin vdir and click on Permissions and add the user you want to give permissions to.

Alternatively, you can go to <installDrive>\Program Files. Right click on "Microsoft Exchange ActiveSync Administration". Select Sharing and Security and go to Security Tab and add the user here.

Click on Remote Wipe on main page to view partnerships for a particular user and to issue wipe, Cancel wipe and delete partnerships as shown:

The snapshot above shows all the partnerships for user Sync1. The admin issued a RemoteWipe for DeviceID=Device1 and DeviceType=PocketPC which was acknowledged by the device. The data shows when the Wipe was initiated, when it was sent to the device, when the device acknowledged it and the status of the wipe command which in this case is the wipe operation completed successfully.

Also note, that DeviceID=NSFJITNAA has not yet sent acknowledgement yet.

If a user does not exist or does not have any partnerships an error message will be displayed which will specify if user does not exist or mailbox is not enabled or no devices were found for that mailbox.

Using PROPPATCH to issue Remote Wipe

A remote wipe is requested by setting the "wipeinitiated" property on the mailbox of the user to a non-zero time value.  By "the mailbox", I really mean the folder where we store sync related stuff.  For a user of "salman", a device type of "smartphone", and a device id of "testdevice", that folder would be:

/exchange/salman/NON_IPM_SUBTREE/Microsoft-Server-ActiveSync/smartphone/testdevice

We can issue a PROPPATCH to set this property.

PROPPATCH /exchange/<mailbox>/NON_IPM_SUBTREE/Microsoft-Server-ActiveSync<DeviceType>/<DeviceID>

Host: <Server>

Brief: t

Accept-Language: en

Content-Type: text/xml

Content-Length: 406

Connection: Keep-Alive

 

<?xml version="1.0" encoding="utf-8"?>

<propertyupdate xmlns="DAV:" xmlns:A="AirSyncCustom:">

 <set>

  <prop>

   <A:wipeinitiated>2005-03-22T00:00:30.078Z</A:wipeinitiated>

  </prop>

 </set>

</propertyupdate>

The specific time isn't important -- the only thing that matters is that it is non-zero when mapped to a FILETIME, where zero means something like January 1, 1601.

What Happens at Protocol layer

At protocol level, the server determines the admin has scheduled the device for remote wipe and sends back HTTP 449 in response. The device then provisions and acknowledges receipt of the remote wipe and subsequently executes the Remote Wipe command.

When the admin schedules the device for remote wipe, and the user issues a provision command, it sends down a Remote Wipe element indicating that the recipient is to initiate the remote wipe sequence.

In the 2nd phase or Acknowledgement part of provision command, an acknowledgement is provided that the remote Wipe directive has been received. Upon receiving the remote Wipe from the server via Provision response, the client issues an acknowledgement indicating its success or failure in receiving it. The status of remote wipe should only indicate success if device processed command correctly and intends to execute a wipe of local contents.

When we process a PROVISION command for a device that is to be remote wiped, we consider the following:

Timestamp Value

Remote Wipe bit True?

State Description

Action

Sent:<time>

Yes

Client didn’t ack last time and is re-sending PROVISION (i.e. if PROVISION response from server was lost last time)

Issue PROVISION response with remoteWipe element

Default

Yes

Expected case.  Device is connecting for the first time after admin specified remote wipe

Issue PROVISION response with remoteWipe element

Ack:<time>

Yes

Error – implies that device ack’d but did not carry out remote wipe command.

Issue PROVISION command with remoteWipe element



This shows up on the webpage as:

Tuesday, July 05, 2005

Microsoft Management Pack Notifier for Microsoft Operations Manager 2005

The Microsoft® Management Pack Notifier Management Pack enables the generation of Informational alerts as updated management pack are released.

Once installed this Management Pack will periodically contact Microsoft to determine if updates to previously installed management packs are available for download. When an update is detected an Informational alert will be generated indicating which management pack(s) and version(s) are available.

Download At Source
News Source: www.microsoft.com

Microsoft SQL Server Report Pack for Microsoft Office SharePoint Portal Server 2003

The Microsoft SQL Server Report Pack for Microsoft Office SharePoint Portal Server 2003 is a set of 8 Microsoft SQL Server 2000 Reporting Services reports that work with a sample database of information extracted from a SharePoint Portal Server environment. This database can be populated from your own SharePoint Portal Server environment using the downloadable Data Extraction Program (DEP). The DEP will read the SharePoint Portal Server data via the object model. You also can use the sample reports as templates for designing new reports.
This Report Pack includes the following reports:

  • Storage Report
    Shows a listing of the virtual servers and the number of collections, sites, areas, lists, files and size. Also shows a size distribution and storage usage chart, and a top 20 sites based on size.
  • Storage Trend Report
    Shows four charts illustrating the virtual server storage trend, site collection growth trend, area growth trend and list growth trend.
  • Site Trend Report
    Shows hit counts for virtual servers, collections, areas and lists. Also shows the top 20 sites based on hits.
  • Comprehensive Site Collections Report
    Shows the list of site collections, who owns the collection, configurable characteristics about the owner and the date the collection was last accessed.
  • Detailed Site Collection Report
    Shows top 20 pages accessed (based on hit count) for this site collection.
  • Detailed Page Report
    Shows users who have access to the page, when they last accessed it, any referrer URL and number of hits. Also shows two charts illustrating user distribution and referrer distribution.
  • Best Bet Keyword
    Shows top 20, top 10, bottom 10, or bottom 20 keywords used for searching. Also shows which keywords have best bets.
  • Search Terms
    Shows top 20, top 10, bottom 10, or bottom 20 search terms used for searching. Also shows which search terms match a defined keyword.

Download At Source
News Source: www.microsoft.com