I've been working in a meeting management app using EWS SOAP service (Exchange 2010 SP1), but for meetings created on behalf of a certain user I cannot know who is this user when I try to get the meeting data through EWS SOAP.
In Outlook (2010 specifically) I can see the name of the account who has acting in behalf of another account on a meeting request for accept or rejection (e.g. Some User ; on behalf of; Another User ), then I want to retrieve the same information through EWS.
I tried to retrieve the meeting information using the example of https://msdn.microsoft.com/en-us/library/office/dn439786(v=exchg.80).aspx changing the Element IdOnly by AllProperties
but I cannot see the property that define who acted in behalf of this account
Is there any way to obtain this user's email or name?
I believe that you need to check this on the meeting request, not the appointment. Check the From and Sender, as I recall the Sender would be the delegate, and the From would be the delegator (though I may have them switched :))
Related
I need to create an application that sends emails by MS Graph but also I need somehow restrict it for few mailboxes who will sending email (e.x. avoid send mail as ceo). Before I used just Sytem.Net.Mail and because basic authentication is now deprecation I must find new way to sending mails.
So I registered new application AAD, I added API permission for MS Graph Mail.Send (application type). Now I want to add restricting for that Graph API (I want to limit who can send a message from this API.
I found that I must use New-ApplicationAccessPolicy cmdlet, but before that I created Mail-enabled security group.
Then via PowerSell I addes new policy:
New-ApplicationAccessPolicy -AppId "9e48a326-a952-42ca-882f-ff1eec699ba7" -PolicyScopeGroupId "SMTPOAuth2SecurityGroup#consto.onmicrosoft.com" -AccessRight RestrictAccess -Description "SMTP OAuth2 Connector"
Then I added two accounts AlexW and DiegoS - both are from Microsoft 365 Developer Program, so both were not modify by me in any way:
Test-ApplicationAccessPolicy -Identity "AlexW#consto.onmicrosoft.com" -AppId
"9e48a326-a952-42ca-882f-ff1eec699ba7"
AppId : 9e48a326-a952-42ca-882f-ff1eec699ba7
Mailbox : AlexW
AccessCheckResult : Granted
Test-ApplicationAccessPolicy -Identity "DiegoS#consto.onmicrosoft.com" -AppId "9e48a326-a952-42ca-882f-ff1eec699ba7"
AppId : 9e48a326-a952-42ca-882f-ff1eec699ba7
Mailbox : DiegoS
AccessCheckResult : Granted
But now I test my application. AlexW can send mail but for DiegoS (or random person) I got erorr:
DiegoS#consto.onmicrosoft.com:Code: ErrorAccessDenied Message: Access
to OData is disabled. ClientRequestId:
909c72f7-02b7-4697-afd5-3d65a58d47a5
I try to remove and again add, wait some time and still the same problem.
So, I need to create an application that sends emails by MS Graph but aslo I need somehow restrict
According to your description, I captured these key words: use graph api to send email, allow specific user to send email, api permisssion with application type. Then let's see the necessary parameter to send an email: sender, content, receiver.
Per my understanding, since you used application type permission, then you want to use client credential flow to generate access token and calling graph api to send the email, so you have to create an azure ad application(done), then you need to specify the sender(set restriction so that only AlexW and DiegoS can do it). Receivers and content are based on the requirement so we don't need to take them into consideration.
Here's a code snippet to send email via ms graph api. The only point we need to consider is how to set the sender user principle now.
Then here're 2 scenarios. If you need to ask users to sign in first then they can send email? Or what you created is just an API so that you only need to receive a parameter(e.g. parameter is the user principle used to send email) then use it to send email?
If you want to integrate the authentication then you can restrict users to access your app, then Azure ad already provided the feature to allow specific users to sign in then the ones who are allowed to sign in can send email, since they already signed in, we can certainly get the user principle.
If you just want to provide a web api, then you may store the users who are allowed to access your api into the database to so that you can check if the incoming request is legal...
Is there any way to read mails from group email id or is there any way to read emails without graph api?
And also is there any way to restrict graph api token to read only from desired email account?
You should use GET /users/{id of group email}/mailFolders/{id}/messages to read mails from group email id.
See reference here.
If you want to restrict graph api token to read only from desired email account, you should implement Get access on behalf of a user. Then you will be able to access the signed-in user's email only.
To answer your first question, the following call will get you the emails in a group mailbox.
GET https://graph.microsoft.com/v1.0/groups/{group-id}/conversations
Can you ask your second question in a new post as it is not related to the first? Make sure you provide information about what you are doing. What auth flow are you using?
We have a Powershell script that creates some guest users using the New-AzureADMSInvitation cmdlet, and its return value has a handy-dandy InviteRedeemUrl property that we include in a nice welcome email to the user to get them started with setting their account up and using our application. This works fine when inviting individual or small numbers of users.
However, we'll need to do this for many users, and carefully control when the emails go out, and I can't see any other way of retrieving this URL after-the-fact... the only option seems to be the "Resend invitation" button on the guest user in AD, which sends a Microsoft-branded email from "Microsoft Invitations" with the redeem URL, which is kind of a problem... For marketing reasons we need to put the invite redeem URL in our own welcome email, so we don't want Microsoft sending out those emails.
Is there any way to retrieve or calculate that invitation URL after the guest user had already been invited? I know I could delete and recreate the invitation itself, but that's still a manual process and I'd like to be able to create guest users in bulk first, and then retrieve those URLs in bulk once we're ready to send out emails. Especially since Azure AD itself seems to be able to fetch the redeem URLs later on via the "Resend invitation" button.
Alternatively , you can think of adding you company branding in the verification and invitation mails in azure AD.
Here is something similar you can find:-
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-faqs#how-do-i-customize-verification-emails-the-content-and-the-from-field-sent-by-azure-ad-b2c
Basically you need to change the company branding in Azure active directory to have your custom logo and text.
Hope it helps.
We ended up modifying the AD invitation script to store the InviteRedeemUrl value in our CRM as a field on the customer record. Then later on when our Marketing team wants to start their email campaigns, they could include a reference to this field in the email template just like they would any other field. This way, we got all our analytics on click/open rates and retained complete control over the emails, including where each batch was being sent from (so customers could reply to the correct support staff member for their segment).
I am doing some work on Lync/Skype meeting integration. In order to make this work, I need to get hold of the GRUU/SIP information for events/meetings.
Currently I have some success by using EWS against Office365. I query for the OnlineMeetingConfLink extended property, and if the meeting is Skype-enabled, get the SIP.
However, when this meeting is forwarded to our own Exchange (2010 SP2), these properties are not added to the invitation. They are not present in any headers or anything.
The message body contains the Lync URL and Skype Conference ID, but those are not usable/parsable in a reliable way.
Any pointer to documentation or suggestions are welcome.
a customer wants enable a chat/instant messenger for his application webside. He is using Lync Server internally to Chat in-house. Now, he requires the following:
A external user (which will not be an AD user) logs into the webside is able to chat with a person inside the company. The internal user will receive those messages via his lync client.
What's the best way to achieve this?
i thought about bot that delegates messages from the webside to the lync server that does the rest. But how can i send a message as an external user?
The usual way to approach this is with the following components:
A bot that connects to the internal Lync infrastructure as an ApplicationEndpoint, and manages conversations with external/internal users
A Web or WCF service that exposes methods over http to external users - this could be built into the bot, or could be a separate service that communicates with the bot in some way
The web UI for presenting a users presence, allowing click-to-call, initiating and displaying a conversation etc
As an example, the WCF service could expose a few methods:
GetPresence(targetSipUri) - returns a presence value for the given uri
SendIM(targetSipUri, message) - sends an IM to the given uri
GetReplies() - polls for any responses
When you get into the detail you might need more methods - e.g. it may be an idea to generate a conversation token and pass this around
The web UI could present a list of contacts with a presence status (GetPresence), then allow the user to click a presence contact to initiate a new conversation window and send the inital message (SendIM), then poll the service for any replies from the contact (GetReplies) - note, the bot will have to queue replies internally until GetReplies is called.
There are commercial products that might meet your needs - a quick search for Lync webchat should turn up a few. Also, it may be worth looking into the Lync Web App, to see if this works for your customer
Edit: In answer to the comment below - yes, your internal users will see a conversation from "Our Lync Bot". If you don't know who your users are (e.g. random potential customers browsing a shopping site), you can grab some info from them (name, product to discuss etc) and have the bot display this to the internal user, either as part of the IM conversation, or as conversation context displayed in a Conversation Window Extension.
If your external users are known in advance (e.g. registered customers), and the internal user MUST see the conversation as being from them, then you will need to create a UserEndpoint for each conversation - but this would rely on having the user in AD.