Outlook anmoder tit om data.

har det noget med synkronisering at gøre - bare et skud i tågen?

Outlook's Requesting Data pop-up box
With the introduction of Outlook 2002 came the popup dialog that is displayed when Outlook 2002/2003 has to wait longer than 5 seconds for a response from an Exchange server or global catalog server.  You can tell from the dialog box what server might be causing the delay.  From the Understanding and Troubleshooting Directory Access whitepaper: “Tip: If the server name shown in the Requesting data … dialog box is in the FQDN format, Outlook is waiting for a response from the directory service. If you see a short server name, Outlook is waiting for either the mailbox server or public folder server to respond.”

A little info... When using Outlook in MAPI mode, user actions in Outlook translate to remote procedure calls (RPCs) between the clients and the server.  If the user is running in online mode, these RPC calls occur synchronously.  Any delay by the server in fulfilling these synchronous requests directly affects user experience and the responsiveness of Outlook. Conversely, running in cached mode results in the majority of these requests being handled asynchronously.  Asynchronous processing means that the speed at which most user actions are initiated should not translate into the responsiveness or overall experience of Outlook.

So when an end-user complains of seeing the dreaded pop-up in Outlook, there are some common things you, the Exchange admin, can do to try and find where exactly the source of the latency is coming from.  Once you have that information in hand, you should hopefully have a starting place for your troubleshooting efforts.  (These are not listed in any particular order) 

Take note what is referenced in the pop-up message.  Using the tip mention above, is it in the NetBIOS or FQDN format?  What server is listed?  This information could certainly be useful when troubleshooting an issue.
Use Performance Monitor.  During the time of the pop-ups gather performance data from the server.  Look closely at the “MSExchange IS” object, more precisely, the RPC counters within that object.  Generally, spikes in RPC requests that do not increase RPC operations/sec indicate that there are bottlenecks preventing the store from fulfilling the requests in a timely manner. It is relatively simple to identify where the bottlenecks are occurring with regards to RPC requests and RPC operations/sec. If the client experiences delays, but the RPC requests are zero and the RPC operations/sec are low, the performance problem is happening before Exchange processes the requests (that is, before the Microsoft Exchange Information Store service actually gets the incoming requests). All other combinations point to a problem either while Exchange processes the requests or after Exchange processes those requests.
Use Network Monitor.  By capturing concurrent traces from a client seeing the pop-up and that user’s mailbox server, you should be able to see where the source of the latency resides (i.e., determine if it is the Exchange server, or the network, or the user’s PC, etc.).  For example, in the client-side trace you should see the request to the server.  In the server-side trace you should see the request arriving from the client and shortly thereafter see the server response to the client.  Back again to the client trace, you should see the server’s response arrive.  When taking this approach, it is important to consider the amount of time that is spent at each point for each request/response.  Obviously, if you see that the server responses are taking an abnormal amount of time to be generated in the server trace, you have some kind of bottleneck on the server.
For more information on troubleshooting specific bottlenecks, check out the performance whitepapers for either Exchange 2000 or Exchange 2003. 

Taget fra:
http://blogs.msdn.com/mfp2/archive/2004/03/08/86204.aspx

og der er også noget response på den......

Ok.. Der er da lidt sporing at gå igang med... Men der er jo kun en vej frem... For det er ret irriterende for de klienter der hele tiden skal vente på serveren.. :-)

Kan det evt. have noget at gøre med at en tidligere DC er blevet fjernet uden de-promovering (eller hvad det nu hedder). Det er godt nok lang tid siden - før mig - men alligevel. Kan det skyldes sådan noget?

Det kan det evt. godt, det er ikke noget jeg er sikker på men det er et bud.....
For den vil jo være en "del af" domainet ind til den bliver de-promoveret.......

Ja.. det er jo det.. Jeg skal have den fjernet med ntdsutil om et par uger... Skal lige vente til et mindre kritisk tidspunkt hvis det skulle slå fejl..
Kan ikke se nogle specielle udsving i RPC.. Om det skyldes mine evner eller at de ikke er der, det er så et andet spørgsmål.. :-)

hejsa, er det outlook 2003 ?

Hvis det er Outlook 2003, så ved jeg at der findes et hotfix til dette, og kan poste linket til dig hvis du skal bruge det !

drukkenbolden -> Det er outlook XP - er der et fix der også?

Nej desværre ikke, det eneste jeg ved er dette fix til outlook 2003:

http://support.microsoft.com/default.aspx?kbid=331320

Men du kan da altid prøve og se om der skulle være nogle opdateringer på http://officeupdate.microsoft.com

Jeg har lavet en offline defragmentation på exchange databasen. Det ser ud til at have afhjulpet problemet.. Samtidig faldt den fra 13GB til 6Gb.. wauv..


Så det var vist ingen af jer to hvis jeg husker rigtigt.. Men tak for hjælpen..

Hej,

Skal lige høre, jeg stå selv i samme situation med "anmoder om data" - men jeg er ikke helt med i hvad "offline defragmentation på exchange databasen" er?

Findes der et sted jeg kan læse om hvordan det gøres? :)

Ville lige sige jeg har oprettet et spm. her -> http://eksperten.dk/spm/621734 - så der også nogle point at komme efter! :)