ActiveSync Stops Working
Bilbo <wlpfake<at>email<dot>hal-pc.org>
or perhaps several interrelated problems.
At rather unpredictable intervals, his employees -- all of whom have
Windows Mobile 5.0 equipped phones -- stop getting mail from the
server.
So far, the work-around is to rerun CEICW and allowing it to rebuild
the firewall but not changing the certificate or email options. After
doing this, an event shows up in the application log announcing that
ActiveSync has been loaded and mail starts getting delivered again.
There is a pattern of POP3 Connector errors in the Application Log.
Event 1036 (error 58) followed by Event 1023 followed by Event 1019.
These appear for more than one recipient.
Also, there is occasionally a series of Event 3033 - usually for the
same user -- which complain about the "heartbeat". The actual text
is:
"The average of the most recent [200] heartbeat intervals used by
clients is less than or equal to [540]. Make sure that your firewall
configuration is set to work correctly with Exchange ActiveSync and
direct push technology. Specifically, make sure that your firewall is
configured so that requests to Exchange ActiveSync do not expire
before they have the opportunity to be processed. For more
information about how to configure firewall settings when using
Exchange ActiveSync, see Microsoft Knowledge Base article 905013,
"Enterprise Firewall Configuration for Exchange ActiveSync Direct Push
Technology" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905013).
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
"
I've been unable to make sense of the KB article because it refers to
an ISA configuration issue and this is a SBS2K3 STANDARD EDITION which
has NO ISA.
The workaround I've found is really a band-aid. I don't understand
what's going on here.
Has anyone seen this kind of behavior and found a repair?
TIA,
--
BilBo
Inn Jin [MSFT]
Thank you for posting.
From the description, I understand this issue is that you can't synchronize
with your windows mobile 5.0 phone, after you rerun CEICW, you get event
1036, 1023, 1019 and 3033. If I am off base, please don't hesitate to let
me know.
Base on my experience, event 1036, 1023 and 1019 are POP3 event, event 3033
is error about direct-push. There seems not have some relationship between
POP3 and direct-push. Therefore, let's focus on "event 3033" mainly.
First, I would like to explain what is direct-push and what is heartbeat
==========================
Direct Push
------------------
Direct Push is a client initiated HTTP connection to the server where the
device opens a connection to the Exchange Server and keeps it alive for a
duration known as the heartbeat interval. Basically the client sets up the
connection, chooses the appropriate heartbeat interval and tears down and
reestablishes the connection if and when necessary. The server sends
notifications about new items over this connection and the client
synchronizes to get the new items.
New AirSync command called PING has been introduced for Direct Push. This
command is sent as part of the POST request from the device.
Heartbeat Interval
--------------------
The device specifies the heartbeat interval as part of the PING command.
This dictates how long the server must keep the connection alive. The
device will dynamically converge to the highest possible heartbeat interval
for a given network, based on the mobile operator timeouts, firewall
timeouts etc. The higher the heartbeat interval, the better it is for
battery life. So the heartbeat is optimized for a given network.
More detailed information:
Direct Push is just a heartbeat away
http://msexchangeteam.com/archive/2006/04/03/424028.aspx
Back to the issue, please follow the steps below:
1. I would like to suggest that you strictly follow the Microsoft White
paper to deploying Windows Mobile 5.0 in SBS 2003 environment.
Deploying Windows Mobile 5.0 with Windows Small Business Server 2003
http://www.microsoft.com/downloads/details.aspx?FamilyID=8be70d72-1e5a-4128-
a30c-dafeeb43544d&displaylang=en
I understand you don’t have ISA installed, but do you have any third-party
firewall application? If so, please refer to the white paper above and
configure your application.
2. Ensure that the device is running Windows Mobile 5.0 with MSFP. Direct
Push technology is only available on devices that have MSFP installed.
MSFP is included with AKU2.2. So any Windows Mobile 5 device that has
AKU2.2 supports Direct Push. You can check whether MSFP is installed on
your device by confirming that the OS build number is 14847 or greater. To
do so: On the device, select Start/Settings/About.
Note: Earlier releases of Windows Mobile 5.0 powered devices do not have
MSFP preinstalled. Most mobile operators will be providing software
upgrades for these devices. For information about the availability of MSFP
or whether MSFP is already installed on your device, contact your mobile
operator or device manufacturer.
Meanwhile, please ensure that the device is not connected to a computer
(cradled) or connected to wireless LAN. Direct Push only works with
over-the-air sync.
3. Please check if you have enabled "Enable Direct Push over HTTP" (ESM ->
Global Settings -> Mobile Services -> Properties -> General tab) on the
exchange server. If not, please check it and then test the issue again.
4. Please check if you have installed the update 916640 on the SBS server.
Detailed information is addressed in the following article:
Direct Push does not work in Exchange Server 2003 SP2 after you create a
secondary virtual directory
http://support.microsoft.com/?id=916640
5. If you have some hardware firewall. This issue may occur if the firewall
has not been configured to let HTTP(S) requests live longer than the
minimum heartbeat interval that is configured on the server that is running
Exchange Server 2003 SP2. By default, the minimum heartbeat interval at
which the Exchange server triggers this event is nine minutes
so you should changing the time out settings for the http and https rule in
your hardware firewall. About how to configure the setting, please contact
your firewall vendor.
Second, for the POP3 event.
=======================
Please make sure you server doesn’t infect MyDoom. It’s very possible
caused by the MyDoom virus, so I would like to suggest that you check the
following web site first:
What You Should Know About the Mydoom and Doomjuice Worms
http://www.microsoft.com/security/incident/mydoom.mspx
If it is not your case. The main cause of the issue is the router
incompatibility with the Windows Server. As root cause is concerned, it is
the Maximum Transmission Unit (MTU)'s difference on the Windows Server and
hardware router.
We have identified this issue will occur on Linksys router BEFVP41/BEFSR41.
As I know Linksys has released the KB article KB10934318 and KB10934351 for
it. You could consult the Linksys support for more information.
On the SBS server, you could use the following method to check the MTU size.
Getting the maximum MTU Size from the SBS server and router
1). To get the MTU Size maximum, you may need to have the following command
on one of internal client connected to SBS server directly.
ping <SBS_IP_address> -f -l <packet_size>
and on SBS server, please ping the POP3 mail server with following command
ping <POP3MailServer_IP_address> -f -l <packet_size>
Being:
<SBS_IP_address or POP3MailServer_IP_address > - the IP address from the
internal network.
<packet_size> - the packet size to test the maximum MTU packet size.
You can use some <packet_size> parameters to get the packet ideal size.
This can be identified by the ping results, for example, ping 192.168.18.8
-f -l 5000
If the ping result is like below:
Pinging [192.168.18.8] with 5000 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 192.168.18.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
You may need to decrease the <packet_size> until encounter a non-fragmented
packet size the link can answer like below:
Pinging [192.168.18.8] with 1472 bytes of data:
Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
Reply from 192.168.18.8: bytes=1472 time<1ms TTL=128
Ping statistics for 192.168.18.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Or else, in this case, the maximum MTU Size is 1472. It is by default
number for SBS 2k3 server.
If you find the router Maximum MTU size is smaller than SBS server, You may
need following tweak
Modifying the MTU Size:
1) Go to the key:
KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfa
ces
2) Go the key corresponding to the NIC GUID
3) Create a Dword parameter 'MTU' with the value small than router
size
4) Restart the server.
Third
==============
If the issue persists, please kindly gather the following information.
1. How many users affected? Some specific ones or all?
2. Please gather the IIS Metabase and IIS log.
IIS Metabase.
-----------
a. Download the IIS Resource Kit tools from the following page:
http://www.microsoft.com/downloads/details.aspx?FamilyId=56FC92EE-A71A-4C73-
B628-ADE629C89499&displaylang=en
b. Install it, run MBExplorer (Metabase Explorer)
c. Right click the "LM" node and choose "Export to file".
d. Specify a file name, specify the password and finish the export.
e. Send the file and the password to me
IIS log:
------------
a. On Exchange Serves, open IIS MMC, right click Default Web Site and then
click Properties.
b. Click Website tab and then check Enable logging.
c. Stop the Default Website and RENAME the existing IIS log files under
C:\WINDOWS\system32\LogFiles\W3SVC1.
d. Restart the Default Website and reproduce the problem, which will
generate new IIS log file with the exact error.
e. Go to the following folder on Exchange Server:
C:\WINDOWS\system32\LogFiles\W3SVC1.
f. Send me the log files to my working email address v-in...@microsoft.com.
3. Download and run the network MPS report tool On the SBS 2003 server
a. Visit
http://download.microsoft.com/download/b/b/1/bb139fcb-4aac-4fe5-a579-30b0bd9
15706/MPSRPT_NETWORK.EXE to download the file.
b. Run the MPSRPT_NETWORK.EXE on the server box.
c. Wait for 10~15 minutes.
d. Open Windows explorer, navigate to
%systemroot%\MPSReports\Network\Reports\Cab
e. Send the .cab file directly to me at v-in...@microsoft.com
4. Please create a new test account for me so that I can perform test to
verify whether the Direct Push works or not in your end. Please let me know
the following information.
- Credential of this test account
- The public URL of your Exchange Server
- Domain name
To keep these confidential, please let me know by mail:
v-in...@microsoft.com
I appreciate your time. I am happy to be of assistance to you and look
forward to your reply.
Have a nice day!
Best regards,
Inn Jin (MSFT)
Microsoft CSS Online Newsgroup Support
Get Secure! - www.microsoft.com/security
=====================================================
This newsgroup only focuses on SBS technical issues. If you have issues
regarding other Microsoft products, you'd better post in the corresponding
newsgroups so that they can be resolved in an efficient and timely manner.
You can locate the newsgroup here:
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx
When opening a new thread via the web interface, we recommend you check the
"Notify me of replies" box to receive e-mail notifications when there are
any updates in your thread. When responding to posts via your newsreader,
please "Reply to Group" so that others may learn and benefit from your
issue.
Microsoft engineers can only focus on one issue per thread. Although we
provide other information for your reference, we recommend you post
different incidents in different threads to keep the thread clean. In doing
so, it will ensure your issues are resolved in a timely manner.
For urgent issues, you may want to contact Microsoft CSS directly. Please
check http://support.microsoft.com for regional support phone numbers.
Any input or comments in this thread are highly appreciated.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Bilbo <wlpfake<at>email<dot>hal-pc.org>
That's quite a laundry list. It'll take me some time to work through
all your information and suggestions. But I'll post back when I have
anything to report.
Thanks again,
Bilbo
--
BilBo
Inn Jin [MSFT]
Just want to say please take your time to schedule your work. After you
performed our suggestion, please do tell me the result. If you need further
assistance, please feel free to let me know.
Bilbo <wlpfake<at>email<dot>hal-pc.org>
This may be premature but I'm marking this server as tentatively
cured.
The situation was VERY complicated to say the least. At least part of
the time, the AT&T feed to the ISP was configured incorrectly
resulting in terribly impaired Internet connection performance. (This
problem was corrected by Monday evening and POP3 Connector has
complained far less than previously.)
Added to that, the client had installed the AVAST 4.7 AntiVirus to a
SBS 2K3 server that is also running the database engine for
QuickBooksPro.
There were LOTS of Logged Events but I'm beginning to believe the key
symptom was a 2011 Event which alerted to a problem with the default
HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\LANMANSERVER\PARAMETERS\IrpStackSize
value of 15.
Late today, I increased this value to 20 and the symptoms have all
vanished ---- at least for the time being.
We're having icy weather conditions here in Houston right now and I
feel it's premature to claim the problem is fixed but at least the
sheer number of symptoms has been dramatically reduced.
If anything else pops up on this, I'll re-open the thread. In the
meantime, thanks for your help and patience.
Bilbo
--
BilBo
Inn Jin [MSFT]
Thank you for upgrading.
I'm happy to hear that your problem is solved, I understand that after
changing the IRPSstackSize to 20, you problem seems to be solved. Event ID
2011 means your IRPSstackSize is too small, the increment you made is
correct. IRPSstackSize specifies the number of stack locations in I/O
request packets (IRPs) used by the server. It may be necessary to increase
this number for certain transports, MAC drivers, or file system drivers.
Each stack uses 36 bytes of memory for each receive buffer. Depending on
the hardware configuration of a specific computer, the default value may
not be large enough for the Srv service to properly administer shared
directories on some of the physical drives.
I'm happy to be assist you, if you have further concerns, feel free to post
here!