So SharePoint 2010 has this handy new calendar overlays feature which allows you to render up 10 other calendars inside of one master SharePoint calendar. There is an option to pull from Exchange calendar as well. The only parameters it provides is the OWA url and the OWA web service url.
We use Exchange online and it isn't working whatsoever. I don't see any fields that store the credential information to connect to Exchange anywhere, and we get back a message saying that there is no email address configured in the profile (there really is). Documentation on the web is sparse for this. My questions are:
Is there a place where I can set credentials for this connection (if so where)?
Can I have it link to shared group calendars in Exchange not just an individuals calendar?
Will this work with MS hosted Exchange online?
I eliminated the "no email address configured" message by adding my exchange email to my SharePoint user profile.
It should pass the current user's credentials (used to connect to SharePoint) through the source services.
So far, I've been unable to connect to shared calendars in Exchange successfully.
Related
We’re trying to determine if some of our customers could use our outlook add-in and we are finding it difficult to determine this information from the web page Outlook JavaScript API requirement sets Documentation
Our add-in uses requirements set 1.5. We have customers using Exchange 2013 and 2016 (on-premise) along with an exchange web portal to access their mailboxes. Is this the same as Outlook on the web or is this different?
Can a customer use Outlook on Android or iOS along with any email account (say gmail) without having to use Office 365? How do roaming settings work in this case?
Currently we are creating users in Azure AD through Azure AD Graph API. Our users, among other thinks, uses Sharepoint Online and Skype for Bussiness Online. All of our users have his mailbox in an Exchange 2010 (on-premise), so they don't have the Exchange Online Plan. For Skype for Bussiness integration with Outlook, it's needed that the mail attribute on the Azure AD object be the same as the mail address in Outlook. The problem is that this attribute is read only throug rest API, and only is populated when you assign a Exchange Online plan to the user. Also, in Sharepoint Online, we can't send notifications to these users because they sharepoint profile doesn't have an email address.
How I should inform the email adress to an Azure AD User using Rest API?
Regards
Our SharePoint environment uses Claims Based Authentication - using
FBA for external users and AD for internal users.
I have not been able to connect using default credentials or Windows
authentication to a test SharePoint site using the SharePoint Client
Side Object Model (CSOM). I am able to connect using an FBA user but
require connecting using default credentials (assuming this is the
app pool id tied to the SharePoint application) or at least an AD
account.
The message I get when executing ClientContext.ExecuteQuery is - Cannot Contact Site at the Specified URL. I
have researched this extensively and have tried numerous suggestions including the following:
Using an event handler tied to the clientContext.ExecutingWebRequest
which adds to the WebRequest headers. Solution found here
https://social.technet.microsoft.com/Forums/office/en-US/16cd0e26-8f3b-4ef2-bac4-c2c59849ab96/authentication-in-clientcontext-in-sharepoint-2010?forum=sharepointdevelopmentprevious.
Using System.Net.CredentialCache.DefaultCredentials
Using System.Net.NetworkCredential passing in AD account
Thanks for any ideas or suggestions.
Tom
I should have mentioned that we are using SharePoint 2010 and that I'm trying to retrieve and update user profile properties. As I was beginning to code a solution to do this (using my FBA connected ClientContext), I read that in SharePoint 2010, you can only update user properties using the UserGroup web service. I get an Access Denied when trying to connect via the web service. I believe the ClientContext sits on top of the web services so the scenario/issue is the same. Again, any thoughts or suggestions are greatly appreciated.
Well, after much research, it seems that there is a solution. Adding a header to the request programmatically is the first step. The only issue is that in addition to adding the header, you must add an additional Windows authentication zone to SharePoint. I do not want to add another zone to our production environment.
Since the program I'm putting together accesses SharePoint and non-SharePoint databases, I would like to run it on a non-SharePoint server so I will most likely use an FBA account that is specifically created for this purpose.
In case anyone is interested, here is another link explaining how to add the header to the web request. You will receive an error - Object Moved without adding an additional zone. Here is a link which describes adding a zone.
I am trying to access the IBM Domino Access Services 9.0.1, which is REST based service for accessing all calendar items.
Lets say for getting calendar items for a user , i have to pass credentials of that particular user.
I don't think it is feasible to store the user credentials in the client side and pass the same while accessing those service instead will create one service account in domino server and access the service using the same service account.
Any idea how to configure in the domino side or how can i achieve accessing the calendar service without passing the credentials of the user.
Looking for similar to what we have are having like Exchange impersonation.
Thanks
Anil
It depends on what kind of application you are building. If each Notes calendar owner logs in to your application directly, it is possible to store the user credentials on the client side. Of course, your application would be responsible for securely managing the credentials. On the other hand, your application might require access to each calendar without directly involving the calendar owner. This can be the case for server-side applications.
Your question doesn't specify, so I'll assume yours is the second situation. In that case, you could create a user identity for your application and then add that identity to the Access Control List (ACL) for each mail file. There are two ways to modify the ACL: 1) You can change the design of the master template and let the design propagate to individual mail files, or 2) You can ask each user to delegate access to your application's identity.
The bottom line is the Domino calendar service acts on behalf of the authenticated web user. If that's the calendar owner, the calendar service will have full access to the calendar. If the web user is some other identity, access will be limited to the rights granted in the ACL. For more information about the ACL see this tutorial.
We've been working with EWS Managed services for a while now, however we would like to transition over to using the RESTful API for Office 365.
Is it possible for an application to access all of our users data without their consent? We have an in-house application that we would like to get some O365/Sharepoint data to our users. Using SSO isn't really an option, as we don't want to keep asking our users to give consent (we assume they already give it). Specifically, we want access to calendars and mail.
Are these "service/application level" accounts available in O365 yet? I think I read a while ago that they are on the roadmap but I have not seen anything since.
Would it be best for us to continue using impersonation with EWS for now until it is ready? (For some reason, EWS is painfully slow when getting data, meanwhile our tests with O365 SSO are a great deal faster, but we do not want SSO).
Apologies if this does not meet the requirements for SA questions. Thanks.
EDIT. Daemon and Service Apps are now possible with Office365. Check out this link.
Building Daemon or Service Apps with Office 365 Mail, Calendar, and Contacts APIs (OAuth2 client credential flow)
App-level authentication is coming soon. Basically an organization administrator will have to consent to allow the application access to mailboxes in their organization, then you'll be able to authenticate as the app, rather than acting on individual users' behalf.
I'd say keep working on your prototype using the user consent model that's in place now, and keep an eye on our blog or my Twitter account (#JasonJohMSFT) for the announcement for app-level auth.