What I need is a connector for integrating SugarCRM with Microsoft Exchange server.
I am using SugarCRM CE 6.0.2
There are several solutions of integrating/synchronizing SugarCRM with Microsoft Exchange Server.
The first one as you pointed out is using the open source implementation of Microsoft Exchange Server's protocols from OpenChange. A complete tutorial is posted at the accelerate4.com site you mentioned above.
The official SugarCRM go-to way is using a Riva Integration Server. However there are several applications/plug-ins for synchronizing available: J-ExSync, ZuckerExchange, whereas I don't know about their quality. You might want to search through the application list on SugarForge.
Related
is it possible to delete a SharePoint site redirect through the Graph PowerShell SDK? I recently changed the SharePoint site URL of an existing MS365 group and now the old URL (e.g. https://domain.sharepoint.com/sites/GroupA) acts as a redirect to the new SharePoint site URL (e.g. https://domain.sharepoint.com/sites/GroupB). Since I want to reuse the old URL, I need to delete the redirect first.
The Microsoft docs state that this is possible through the SharePoint Online Management Shell. Unfortunately the Shell requires a Windows-based machine, which I cannot use. Therefore, I am trying to do this via the Graph PowerShell SDK.
Unfortunately, Microsoft does not seem to offer any functionality to delete SharePoint sites via the MS Graph API
The Sites API Reference shows that MS Graph is only capable of deleting a permission object on a site rather than a site itself.
As MS Graph API doesn't expose any endpoint to delete sites, it will not be possible with the Graph Powershell module either.
It's unfortunate that the SharePoint Online Management Shell doesn't support Powershell core and that the SharePoint admin center offers no ability to delete these site redirects.
If you're not able to use a Windows machine to achieve this, I suspect a support call to Microsoft may be your only other alternative.
As NiMux mentioned, it's not possible to delete SharePoint sites resp. site redirects via the MS Graph API. But another alternative is the PnP PowerShell module, which among other things provides several SharePoint Online cmdlets. I was able to remove the redirect with the cmdlet Remove-PnPTenantSite.
The module is open-source, community-developed, officially recommended by Microsoft and cross-platform which means it works on an Azure Ubuntu VM (tested it myself).
I followed official documentation from : https://docs.wso2.com/display/IS541/Integrating+WSO2+Identity+Server+with+Liferay to Login in my Liferay Portal with wso2is user, but it not work for me in wso2is-5.4.1 and liferay6.2ga6. When I try login, liferay's log print "Primary URL :https://wso2is.local:9443/services/Secondary URL :null" but no call to wso2is server is done.
I added this lines into my portal-ext.properties :
auth.pipeline.pre=org.wso2.liferay.is.authenticator.WSO2ISAuthenticator auth.pipeline.enable.liferay.check=false wso2is.auth.service.endpoint.primary=https://wso2is.local:9443/services/ wso2is.auth.thrift.endpoint=localhost wso2is.auth.thrift.port=10500 wso2is.auth.thrift.connection.timeout=10000 wso2is.auth.thrift.admin.user=admin wso2is.auth.thrift.admin.user.password=admin wso2is.auth.thrift.endpoint.login=https://wso2is.local:9443/ wso2is.auth.thrift.system.trusstore=/wso2is-5.4.1/repository/resources/security/wso2carbon.jks wso2is.auth.thrift.system.trusstore.password=wso2carbon
Is there something wrong?
Unfortunately, a lot of the WSO2 documentation is very crufty, containing articles that have been pulled forward from previous versions of the documentation without regression testing on the use cases they present. In short, there's stuff in the documentation that plain doesn't work. If you look at the bottom of the article you'll see the following:
Please note that the above configuration is tested with Liferay 6.1.1
and WSO2 Identity 3.2.3/4.0.0.
I recall I tested this a long time ago, and determined that it wouldn't work with the current version, but that was so long ago that I can't remember why. In any case, the approach presented for integrating Liferay was offered at a time where Liferay didn't have the ability to use standardized authentication protocols like SAML. Now that it does, you probably want to do it in a standards compliant manner instead of using an authentication interface Liferay only promotes using for proprietary authentication systems.
My suggestion is that if you are using Liferay portal enterprise with LDAP that you use the built-in SAML connector. If you aren't using Enterprise, there are some compatible authenticator extensions in the extensions store that will also integrate with Liferay. If you configure Liferay to be a client against WSO2 and then integrate Liferay to LDAP on the backend, it also allows Liferay to be used as a user dashboard instead of the jaggery based one that comes in the product.
I am working on a salesforce project and need to add a package. The issue is that under developer console I am not able to create Apex Classses , which leads to the following error when I add the package to salesforce.
This is the error I get when I try to install the package
After reading many forums, I came to a conclusion that i need to activate Apex Author permission under permission sets.
But the permission is not present there.
I created a developer account for salesforce in which the Apex Classes where already active and was able to import the package and make changes.
The Salesforce account is Professional Edition and is not under trial.
Any help regarding this will be appretiated.
Thanks
Currently, Professional Edition (PE) does not have the ability to create, modify, or deploy Apex classes directly in an org of that edition. This includes using Apex in an unmanaged package. The Author Apex permission is only found in Enterprise, Unlimited, Performance, and Developer editions.
If you are an AppExchange Partner, you can write apps that use Apex, and send them through security review to be installed in PE orgs (as well as Group Edition).
From the Apex Code Developer guide relating to Apex and PE, you can read about the basic statement about Apex and supported editions. In the ISV Developer Guide (for App Exchange Apps and partners), you can read the specifics of what is required to get your app to run with Apex in a PE/GE org.
If you are exploring Salesforce for the purposes of writing ISV apps for Salesforce, I would also recommend taking this short self-paced learning module on ISV basics and Salesforce on the Trailhead learning platform.
Finally, there is a dedicated Salesforce stack exchange you might also look into for further question.
Can someone explain to me why one would use IFD (Internet Facing Deployment) to access Microsoft CRM vs. just using Windows Authentication? They seem equivalent to me in their features. Not sure of the benefits of IFD over Windows auth however.
Thanks!
Take a look at this previous answer for some discussion on this topic: Exposed onsite vs IFD deployments for MS Dynamics CRM
I would say from my standpoint the biggest issue with using Windows Auth over the internet for CRM is the issue of Outlook integration. The second point I would make is that Windows Auth can present issues to people accessing CRM from a non-domain computer when outside the domain - i.e., their home computer. Not always but I have seen issues pop-up (not very often) that are avoided in a forms based configuration.
As a reminder in 2011 the IFD feature has been changed signficantly so that you must use Active Directory Federation Service which is claims-based. I recommend reading over http://blogs.msdn.com/b/crm/archive/2011/01/13/configuring-ifd-with-microsoft-dynamics-crm-2011.aspx and watching the video at http://www.youtube.com/watch?v=ZD5qaa-G99E.
You can certainly go with Windows Auth but if you are willing to put in the extra work go with the Internet Facing setups for a more robust and better supported install.
I want to add to privious answer.
Integrating Outlook client from outside the domain can be done by reseting windows credential in the control panel from time to time.
another complication is SharePoint integration which can't be used outside the domain with SSO.
If you do use IFD, I recommand on this blog:
http://dynamics.co.il/configuring-crm-2011-ifd
Is there any way via powershell or some api that I can't seem to find in the CRM 4.0 SDK, that would allow us to automate the refresh from our production CRM 4.0 environment to a Staging CRM server? Obviously the db backup / restore we can script but I cannot find a way to kick off a CRM Import Organization without using the MMC snap-in.
there is a Deployment SDK for Dynamics CRM 4 available. However the interesting part for you is not part of the public api.
The documentation mentions the ImportOrganizationRequest which should be used by the Deployment Manager. Unfortunately, it is marked for internal use. However, there should be no changes to this API as Dynamics CRM 2011 is just around the corner and therefore I would give it a try.
You could use this post in the msdn forums as a starting point.
btw: Dynamics CRM 2011 comes with a set of PowerShell CmdLets which makes the adminstration much more scriptable. Especially Import-CrmOrganization would be the CmdLet which you could use. See my blog post for further information.