IIS iisreset, recycle, refresh and restart – what are the differences?

Have you ever wondered what is the difference between iisreset, recycle, refresh and restart?

 

Here is great post that answers all the questions:

http://serverfault.com/questions/247425/what-is-the-difference-between-iisreset-recycle-refresh-and-restart

 

Vlad Mucescu explains that:

“As pointed out, iisreset will stop and start the World Wide Web Publishing Service. This, of course, applies to all of your application pools. I’m sure you noticed a process being created for each application pool. This process will handle requests for all websites associated with it. When you recycle an application pool, IIS will create a new process (keeping the old one) to serve requests. Then it tries to move all requests on the new process. After a timeout the old process will be killed automaticaly. You usualy recycle your application pool to get rid of leaked memory (you might have a problem in your application if this needs to be a regular operation, even though it is recommended to have a scheduled recycle). As for restarting a website, it just stops and restarts serving requests for that particular website. It will continue to serve other websites on the same app pool with no interruptions.

If you have a session oriented application, all of the above will cause loss of session objects.

Refreshing a websites has no effect on the service/process/website and is meerly a UI command to refresh the treeview (maybe you added a directory you don’t see in the management console).”

Advertisements

Exchange Message Tracking – finding out if message was recalled properly.

That kind of situations really tend to happen when you need them at least.

Friday evening, you are about to go home from the late shift you have just covered, you have maintained your infrastructure today having in mind that there will be FINALLY a free weekend without any work and…

BAM!

surprise2

One user is urgently asking for urgent favour, he sent urgent email to urgent people about urgent things, but it was so fu*king urgent he made a mistake and urgently recalled it and now you urgently need to find if that recall was successful.

First thing you think. Remember – you were just about to leave the office:

kill_madafakaLater you try the easiest solution, you ask him to check his fu*king mailbox for an recalling email and he says: “Do not know how to do it, maybe deleted it, it was so quick, all that technology! Can you help urgently?!”

So after that kind of dialogue on the phone:

59495275

Normally when user is recalling a message he/she is getting en email saying that message was recalled successfully or not.

For SUCCESS:

recall_success

For FAILURE:

recall_failed

But what happens when user for example sends an email as a Distribution List? The recall confirmation will not  come to any mailbox. And here Message Tracking comes with help!

When user recalls the message there are two messages in the Message Tracking logs: NOTIFYMAPI and SUBMIT:

Only the following columns were included: “timestamp, eventid, sender, messagesubject, recip*,sourcecontext”

Timestamp       : 10/2/2015 3:14:25 PM
EventId         : NOTIFYMAPI
Sender          :
MessageSubject  :
Recipients      : {}
RecipientStatus : {}
RecipientCount  :
SourceContext   : MDB:1ac8faa2-280e-47a3-ae55-1b4cb0205c91, Mailbox:891984d2-0598-4e25-9d92-55058ec2daf2, Event:51849, MessageClass:IPM.Outlook.Recall,
CreationTime:2015-10-02T22:14:24.561Z, ClientType:MOMT

Timestamp       : 10/2/2015 3:14:26 PM
EventId         : SUBMIT
Sender          : testuser1@zaic12.local
MessageSubject  : Recall: recall myself 22
Recipients      : {testuser1@zaic12.local}
RecipientStatus : {}
RecipientCount  : 1
SourceContext   : MDB:1ac8faa2-280e-47a3-ae55-1b4cb0205c91, Mailbox:891984d2-0598-4e25-9d92-55058ec2daf2, Event:51849, MessageClass:IPM.Outlook.Recall,
CreationTime:2015-10-02T22:14:24.561Z, ClientType:MOMT

Please note the message class of the entry, which is IPM.Outlook.Recall.

recall_tryWe also see that it has been send to one recipient, and we have address of that recipient.

You would tell that we might as well can look on the subject of the message to find the right one. Thing is that is nome companies subjects are hidden and all you would see in the MessageSubject attribute would be “[undisclosed]“.

Later, if we have successful recall we will see following entry:

Timestamp       : 10/2/2015 3:14:36 PM
EventId         : NOTIFYMAPI
Sender          :
MessageSubject  :
Recipients      : {}
RecipientStatus : {}
RecipientCount  :
SourceContext   : MDB:1ac8faa2-280e-47a3-ae55-1b4cb0205c91, Mailbox:891984d2-0598-4e25-9d92-55058ec2daf2, Event:51868, MessageClass:IPM.Recall.Report.Success,
                  CreationTime:2015-10-02T22:14:35.815Z, ClientType:MOMT

Timestamp       : 10/2/2015 3:14:37 PM
EventId         : SUBMIT
Sender          : testuser1@zaic12.local
MessageSubject  : Message Recall Success: recall myself 22
Recipients      : {testuser1@zaic12.local}
RecipientStatus : {}
RecipientCount  : 1
SourceContext   : MDB:1ac8faa2-280e-47a3-ae55-1b4cb0205c91, Mailbox:891984d2-0598-4e25-9d92-55058ec2daf2, Event:51868, MessageClass:IPM.Recall.Report.Success,
                  CreationTime:2015-10-02T22:14:35.815Z, ClientType:MOMT

Also please note the class name IPM.Recall.Report.Success.

recall_suc

Of course in case if someone saw the message already opening it on some active sync device for example, we might get failure in the log:

Timestamp       : 10/2/2015 3:06:02 PM
EventId         : NOTIFYMAPI
Sender          :
MessageSubject  :
Recipients      : {}
RecipientStatus : {}
RecipientCount  :
SourceContext   : MDB:1ac8faa2-280e-47a3-ae55-1b4cb0205c91, Mailbox:891984d2-0598-4e25-9d92-55058ec2daf2, Event:51731, MessageClass:IPM.Recall.Report.Failure,
                  CreationTime:2015-10-02T22:06:02.786Z, ClientType:MOMT

Timestamp       : 10/2/2015 3:06:03 PM
EventId         : SUBMIT
Sender          : testuser1@zaic12.local
MessageSubject  : Message Recall Failure: test recall for myself
Recipients      : {testuser1@zaic12.local}
RecipientStatus : {}
RecipientCount  : 1
SourceContext   : MDB:1ac8faa2-280e-47a3-ae55-1b4cb0205c91, Mailbox:891984d2-0598-4e25-9d92-55058ec2daf2, Event:51731, MessageClass:IPM.Recall.Report.Failure,
                  CreationTime:2015-10-02T22:06:02.786Z, ClientType:MOMT

Message class here would be: IPM.Recall.Report.Failure

recall_fail

So we have all needed information in logs including most important if recall was successful, but also info about recipients, number of them, subject, etc. in other words, all we need to help poor user in establishing if his email was properly recalled.

There is just one more situation that might happen – the sender won’t get any information about recall at all. That might be caused by two situations:

  1. recipient (or his delegate – see the link at the end for nice MS KB about that) most probably has unchecked the “Automatically process meetings and responses to meetings requests and pools” option in his Outlook.

recall2

2. Recipient closed his Outlook when leaving home and haven’t turned it on yet.

Important to add is – because message recall feature is an Outlook feature it fully relies in Outlook sniffer mechanism.

To check if recipient indeed has some recall messages in his inbox Search-Mailbox cmdlet comes with help:

Search-Mailbox testuser1 -TargetMailbox administrator -TargetFolder Search -LogOnly -LogLevel full -SearchQuery {subject:”recall” AND received:today}

That will result in an CVS file in which we can see:

recall3

Well and indeed, when we log in to the mailbox via OWA, we see there are 3 recall messages pending:

recall1

If user indeed had unchecked the “Automatically process meetings and responses to meetings requests and pools” option, and we opened those messages in recipients Outlook – by clicking on the small arrow just expanding the thread or by clicking on the thread itself – we will see magic happening as message would be immediately removed on our eyes.

On above example we are looking at the message from OWA – hence recall function will not work. And here is the thing –  although we send a recall for a message recipient, he will be able to see it using ActiveSync, Good For Enterprise, BlackBerry or OWA anyway.

And here is a nice link with message classes (might be useful):

https://msdn.microsoft.com/en-us/library/office/ff861573.aspx

And few interesting words about Outlook sniffer:

https://support.microsoft.com/en-us/kb/2699725

https://support.microsoft.com/en-us/kb/2699728