We have a large amount of meeting requests we need to send out. We would like to prevent the users getting large amount of meeting requests to accept so I have found online the following script to auto accept meetings and then delete from inbox. This is the script:
Sub AutoAcceptMeetings(oRequest As MeetingItem)
If oRequest.MessageClass <> "IPM.Schedule.Meeting.Request" Then
Exit Sub
End If
Dim oAppt As AppointmentItem
Set oAppt = oRequest.GetAssociatedAppointment(True)
Dim oResponse
Set oResponse = oAppt.Respond(olMeetingAccepted, True)
oResponse.Send
oRequest.Delete
End Sub
What I now require is the ability to force all mailboxes in our exchange to run this script when receiving a Meeting request with a specified heading in the subject line.
You would need to create a COM addin that runs that code and install it on all machines where you want to auto accept meeting requests.
If you do not want to check the subject of a request, you can configure each mailbox to auto accept all requests (File | Options | Calendar | Auto accept or decline).
Related
We have a web based windows software with thousands of user. For some actions we send SMS and notification to many users. I don't want to set a long timeout on whole IIS settings. How can I set unlimited timeout only for sending messages?
this is the function that sends SMS to thousands of users:
for x=1 to 1000000
call sendSMS(PhoneNumber(x),"test message")
next
function sendSMS(PhoneNumber,message)
posturl="http://URL TO SMS SERVICE"
posturl=posturl & "username=user"
posturl=posturl & "&password=password"
posturl=posturl & "&dstaddress=" & PhoneNumber
posturl=posturl & "&message=" & server.Urlencode(message)
set xmlhttp = server.Createobject("MSXML2.ServerXMLHTTP")
xmlhttp.Open "POST",posturl,false
xmlhttp.send
myresult= xmlhttp.responseText
end function
I think you're looking for the Server.ScriptTimeout property. You can set it to override the maximum amount of time that the script can run just for that request.
Server.ScriptTimeout = 5000 ' or whatever
Note that it'd generally be best practice to not actually have the connection stay open for a long-running request, but put some sort of message in some sort of queue and have some sort of back-end service that handles the batch processing. But this approach may be adequate depending on your exact requirements.
I am using the EWS Managed API to create appoitments on Exchange 2010.
Appointment appointment = new Appointment(exchangeService);
appointment.Subject = "Sample meeting";
appointment.Body = "Sample meeting body";
appointment.Start = bookingInfo.from;
appointment.End = bookingInfo.from.AddMinutes(bookingInfo.duration);
appointment.Location = meetingRoom.displayName;
appointment.Resources.Add(<my_room_mail>);
// Send the meeting request to all attendees and save a copy in the Sent Items folder.
appointment.Save(SendInvitationsMode.SendToAllAndSaveCopy);
This piece of code create effectively an appoitment in my Outlook but the Meeting Room included as a resource is marked as a "tentative" (not really accepted). So when I want to delete the meeting, the meeting room stay booked (busy/tentative) for the slot and it is impossible to delete the tentative.
If I delete the appoitment from the EWS code (using the appoitment ID), it works as expected, the room is effectively free.
Appointment appointment = Appointment.Bind(exchangeService, new ItemId(itemId));
appointment.Delete(DeleteMode.MoveToDeletedItems);
Do you have any idea of what is the problem ? Outlook right ? Bad appoitment creation or resource booking ?
Ok, I understand that Direct Booking is not compatible with EWS/OWA/Mobile solutions (and also with Outlook 2010/2013 without register tweak).
Direct Booking and Resource Booking Attendant (Auto Accept feature) are conflicting technologies, and if enabled together, unexpected behavior in calendar processing and item consistency can occur.
Check this for more details :
http://msexchangeanswers.blogspot.fr/2009/08/outlook-direct-booking-vs-auto-accept_17.html
http://exchangeserverinfo.net/2013/05/remove-auto-accept-from-outlook-for-all-room-mailbox/
The resource room needs to auto-accept the invitation, so it loses its tentative status. Then when you delete the appointment from your calendar, it should automatically send cancellation to the room. There is a setting on the delete to do this, and I forget off the top of my head if it's the default or not, but I think the initial issue is why the room is not configured to accept or reject the invite sent.
Can anyone help me understand how MAPI works? I have this simple vbscript that uses MAPI to send an email out. It works perfectly fine, but, I don't know how it is doing that...what's happening in the background?
Const ForReading = 1
Set args = WScript.Arguments
sqlFile = args.Item(0)
logFile = args.Item(1)
Dim ToAddress
Dim FromAddress
Dim MessageSubject
Dim MyTime
Dim MessageBody
Dim MessageAttachment
Dim ol, ns, newMail
MyTime = Now
ToAddress = "my#email.com"
MessageSubject = "Subject goes here"
MessageBody = "Body message goes here."
MessageAttachment = ""&logFile&""
Set ol = WScript.CreateObject("Outlook.Application")
Set ns = ol.getNamespace("MAPI")
Set newMail = ol.CreateItem(olMailItem)
newMail.Subject = MessageSubject
newMail.Body = MessageBody & vbCrLf & MyTime
newMail.RecipIents.Add(ToAddress)
newMail.Attachments.Add(MessageAttachment)
newMail.Send
Thanks in advance...
What you are doing in this code above is actually using the installed version of Outlook to send the mail message. Outlook may very well be using MAPI, but the API interface you are actually using here is COM based automation of Outlook. Code such as this will utilize Outlook to send email through any mail transportation system that Outlook can be configured to use. However, that is a lot of overhead just to send an email message. Depending on what email server(s) you might have local to you on your network or via there may be much more efficient ways to send email. But if this works fine and meets your needs currently, don't take that to mean that there is anything wrong with doing it the way you have above. It is all about understanding the tools available to you and how to best apply them to your particular problem space.
In your code, you are controlling Outlook and telling it to create an email message. You are passing off the message to Outlook and then Outlook is actually using the configured profile it has to determine how to hand off the message to a configured Exchange server or other installed/configure mail transport agents (mta).
I'm trying to write an Applescript that will make an outgoing Skype call at times scheduled by received invites from other parties.
I think I'm fine with the script to Skype's API to make the call, however I'm struggling with iCal with either method of
A) getting the script to run in the background and getting the time of all new events, or
B) getting the event alert to run a one-off script.
The issue with option B) is that although you can set events from within iCal so that the alert runs a script, I need to trigger this from events that have been received.
A typical example would be:
All scripts and iCal running on the Host
At 10am a User schedules an event (via google cal on portable device) for 3pm** and invites the the Host.
At 3pm the script on the Host uses Skype API to make a call to the User.
** this could just as equally be on a date in the future and the requirements still hold.
Many thanks for any advice!
Since iCal doesn't have any notifications (some applications do like iChat) you'll have to run a "stay open" applescript application. Something like this will do it for your "B" scenario. NOTE: you will have to add the path to your applescript file (the one that makes your Skype call) in the "applescriptPath" variable.
When launched it will get a listing of all the calendar events you have in iCal. It will then run itself every 5 minutes. When it runs it will check the current events against the list of events it originally made. If there are new events then your applescript will be added as an alarm to the new events. This way it keeps track of the current events between runs and only finds the new ones.
So this script should be a good starting point for you. Remember to save it as a stay-open applescript application. You probably will want to modify it. For example I have it checking every calendar for new events but you may have one particular calendar you want to target. Good luck.
property storedUIDs : {} -- we use this to check for new events, if an event is not in this list then it is new
global applescriptPath
on run
set applescriptPath to (path to desktop as text) & "myAlarm.scpt" -- the path to the applescript which is run as the alarm
end run
on idle
set newEvents to {}
tell application "iCal"
set theCals to calendars
set allUIDs to {}
repeat with aCal in theCals
tell aCal
set theseEvents to events
repeat with anEvent in theseEvents
set thisUID to uid of anEvent
set end of allUIDs to thisUID
if thisUID is not in storedUIDs then
set end of newEvents to contents of anEvent
end if
end repeat
end tell
end repeat
set storedUIDs to allUIDs
if (count of newEvents) is less than 5 then -- this will prevent the first run of the script from adding the alarm to every event
repeat with aNewEvent in newEvents
-- do something with this new events like add an alarm to run an applescript
set theAlarm to make new open file alarm at end of open file alarms of aNewEvent with properties {trigger interval:0, filepath:POSIX path of applescriptPath}
end repeat
end if
end tell
return (5 * 60) -- run every 5 minutes
end idle
on quit
set storedUIDs to {}
continue quit
end quit
I am writing a newsletter application using CDO.Message. But get an error back that we have to many connections. Seems they have a limit of 10 simultaneous connections.
So, is there a way to send several messages on one connection, or disconnect faster?
There is a cdo/configuration/smtpconnectiontimeout parameter, but I think that's more about how long the sender will try.
(If we send,ant it fails, it will succeed again after some minutes, probably meaning that the connection is disconnected).
(We are using CDO partly because we are pulling the HTML message body from a webserver)
Edit:
Public Sub ipSendMail(ByVal toEmail As String, ByVal fromEmail As String, ByVal subject As String, ByVal url As String)
Dim iMsg As Object
Set iMsg = CreateObject("CDO.Message")
iMsg.From = fromEmail
iMsg.To = toEmail
iMsg.Subject = subject
iMsg.CreateMHTMLBody(url)
iMsg.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2
iMsg.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/smtpserver") = "relay.wwwwwwwwww.net"
iMsg.Configuration.Fields.Item_
("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25
iMsg.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/smtpconnectiontimeout") = 0
iMsg.Configuration.Fields.Update()
iMsg.Send()
Set iMsg = Nothing
End Sub
Try to use SMTP instead of CDO, System.Web.Mail.SmtpMail
You could implement a queue, that is processed by a background thread. The background thread would only send one message at a time.
You can store the email in a database table, which is processed by a scheduled task or a stored procedure. Those can again send one mail at a time, and have the advantage of being able to retry, if it goes wrong.
Ordinarily you only need one connection regardless of how many messages you are sending.
Perhaps you are not releasing something that you should be.
Edit: Just a thought, the SMTP server you are sending to, it wouldn't happen to be host on an XP box perhaps for testing reasons?
Edit: Ok so your SMTP server is fine.
What platform is the server supplying the result of the URL?
I know that CDO can be quirky at times, so these are the possible suggestions that I would make:
A queue would probably work the best for you. After that, I would consider setting up a local SMTP server without inbound connection limits that uses a smarthost to queue up your outbound messages. (This could actually be written fairly easily. The "S" is for "Simple" and it actually is.)
If all else fails... You could always roll your own mailer component implementing RFCs 2821 and 2822 (or whatever the latest and greatest RFCs are for SMTP and message format)
EDIT: If the newsletter you are sending out is identical for all recipients, you can address it to a dummy recipient (i.e. newsletter#yourdomain.com) and BCC it to the recipient list (or a subset of the recipient list). Just be careful not to get flagged as unsolicited commercial email. Let your provider know what you are doing. They have to deal with the complaints, and you are the one paying the bill. Letting them know that complaints would be mostly unwarranted (and few and far between) will help to assuage their natural risk aversion.