Claim based authenication is something that will be coming, and will come strong. check this movie about Geneve, and how the technologies around authorization will change the upcomming few years.

the x86 version
the x64 version

Some screenshot on what this tool can deliver:

You want Zarafa with SharePoint Services? no problem, you can use them both, side by side with one username and password.

Hosting Zarafa is a huge accomplishment, because our partners can now decide if they wanne use Exchange or Zarafa. Without the customer switching over towards another Partner. We want to run ALL applications.

Here you see a screenshot right before a customer gets provisioned for Zarafa, notice the multi-ple domain selection and Notification email address.

When the provisioning is finished, you can now provision user, provisioning a user looks like this:

Note the language settings and the mail aliases, everything is there.

When the provisioning is done, the user can use our Single-sign-on Portal for authentication, this portal is used for all our Services. And every Service is using the same user/password combination. Doesn’t matter is the user is in OpenLDAP or Active Directory

When you provided the right credentials, the Zarafa Mailbox will open.

Some facts about Zarafa:

Cost-effective
•initial investment and upgrades cost less than 50% of MS Exchange

Effective sharing via multiple clients
•Effective communication by sharing e-mail, calendar and contacts
•Stable Outlook sharing for all Outlook versions by full MAPI implementation
•Support for IMAP and iCal based clients

Work wherever you want
•Webaccess compatible with Internet explorer and Firefox
•Remote Outlook synchronisation over HTTPS
•Advanced offline mode for laptop users
•Remote synchronisation & push-mail of all ActiveSync compatible PDA’s and phones (Windows Mobile, iPhone, Nokia Mail for Exchange)

Technical benefits
•Freedom to integrate your own Linux MTA, like Postfix, Sendmail or Qmail
•Easy migration: Via migration tools, data can be imported from existing MS Exchange environments or IMAP based solutions
•Multi-user week calendar in webaccess
•Brick-level backup with single item and single mailbox restore
•Integration with existing LDAP environments, like OpenLDAP, Active Directory or eDirectory

Open source & open standards
•Source code available under the Affero GPLv3 license
•Open architecture supporting Apache, MySQL, PHP
•Gateways to IMAP, POP3, iCal, Caldav

Wildcards are not working because the Proxy Principle name is not correct. I got tons of hits on Google about failures with Wildcard certs and Autodiscover. Common error is: “Users will be prompted for credential repeatedly”

When you enable Outlook anywhere with for example mail.domain.com the Autodiscover Outlook Account Settings are:

Because we use a Wildcard certificate; the “Issued by” is not mail.domain.com but *.domain.com. You can change that by the following commands.

Open Exchange Powershell on a Client Access server
• set-OutlookProvider -id EXPR -server $null -CertPrincipalName “msstd:*.domain.com”
• Set-OutlookProvider -id WEB -Server $null -CertPrincipalName “msstd:*.domain.com”

This will do the trick

So now you can do EVERYTHING with a wildcard certificate, also Autodiscover.. below is a screenshot from the Autodiscover XML. Please notice the Proxy address below:

Click Here to download the whitepaper

When you want to enable incomming email, you need to complete the following steps:
1. Create a @sharepoint.something.tld (tld, stands for Top Level Domain)
2. Create a SMTP Service in SharePoint Services
3. Make sure sharepoint.something.tld has a MX record for email traffic
4. Enable SharePoint for Incomming Email

Step 1 – Create a @sharepoint.something.tld
When you have a Hosted SharePoint Service 3.0 environment, the environment is mostly accesable from a wildcard url. for Example *.wss.saas.com
Every customer will have a default Site like https://{sitename}.wss.saas.com

The easiest way for incomming email is configuring using @wss.saas.com. So you have no control over your customer DNS zones in some/most cases to set the MX Record.

Step 2 – Create a SMTP Service in SharePoint Services
Make sure you install the SMTP Service on IIS, you can do that through “Add/Remove Programs”
When the SMTP Service is installed, you need to cofigure the following settings:
- Open IIS 6.0 Manager
- Open the Local Computer
- Open the SMTP Virtual Server
- right click SMTP Virtual Server, and select properties
- Select Access
- Configure Relay Restrictions. Make sure All except below is selected, otherwise SMTP will NOT accept email.

You’ll also see Domains where the local computer name is listed, you need to add an extra domain. Otherwise the system will NOT accept email.
- Right click domains
- Select New – Domain
- Select Alias
- Name will the the wss.saas.com in our example. The SharePoint System will now accept email towards *@wss.saas.com

Step 3 – Make sure sharepoint.something.tld has a MX record for email traffic
When you’re using @wss.saas.com, make sure the MX record is pointing towards your newly created SMTP host on SharePoint
When you external address for SharePoint is 60.60.10.10, you should have the following DNS entry:

C:\Users\Mark>nslookup
Default Server: —–
Address: —-

> set q=mx
> wss.saasplaza.com

Non-authoritative answer:
wss.saas.com MX preference = 10, mail exchanger = 60.60.10.10

Every email towards *@wss.saas.com will be send towards 60.60.10.10 (Make sure your firewall is open for TCP 25 (SMTP) traffic)

4. Enable SharePoint for Incomming Email
Now you can configure SharePoint Services to monitor the “Drop” folder for new emails.
- Start SharePoint Service 3.0 Central Administration.
- Select Operations
- select Configure Incoming E-Mail Settings

Configure Incomming Email settings like the screenshot below:

How can a Customer enable incomming email for his SharePoint Site?

To Mail enable a Document library, follow the screenshots below:

Select “Settings”, and select Document Library Settings

Configure the Incoming E-Mail as desired and Select OK.
Your document library can now receive Email

So how does IFD work, and how can you use it in a Hosted Environment?

When you install CRM4 without IFD (on-premise) you will notice the new customer can access CRM by the following URL:

http://localhost/{customer}

When you publish CRM on the internet (SECURE), the URL will be https://www.crmonline.com/{customer}

This means every new customer will be located after the .com which makes it easy for provisioning because you don’t need to configure extra certificates or connectifity like proxy servers and ISA Servers.

But what if the customer demands the Outlook Client integration? Just enable IFD you think.. but the IFD will change the entire connectifity. When you have your CRM server running with the URL www.crmonline.com you’ll notice that the ISAPI filter in IIS6 is redirecting the customer towards the following URL: https://{customer}.www.crmonline.com. This is not a minor change, it means the entire connectify is changed. Your configured ISA or Proxy will not understand the URL anymore. And the certificate www.crmonline.com is not valid because it’s using {customer}.www.crmonline.com.

So we have to change two more things!
1. Get a wildcard certficate
2. Setup connectifity for the customers
– Wildcard DNS
– Wildcard Proxy

A wildcard certficate is a “must-have” in a Hosted CRM4 environment, one domain certificate is not sufficiant when you have more customers.
So how would the certificate look like? My advice, buy a *.crmonline.com cerficate and make sure IFD is using crmonline.com and not www.crmonline.com.
When a customer is created the IFD enabled URL will be https://{crminstance}.crmonline.com. When the wildcard certificate is enabled on the Server, every compnay will be secured, and you won’t get a warning the URL is wrong.

Your next adcvement will be making sure every new customer is automaticly registered in DNS. You can do that manual (I hate the word manual in Hosting) or automaticly by adding a wilcard DNS entry or a WMI DNS script who adds the entry. We choosed the Wilcard DNS entry, because you don’t need extra steps in your provisioning, and you can still add individial records to dns as long the “mail.crmonline.com” is above the wildcard entry.

Did you know you can also add wildcard DNS entries in ISA? Yes! and it works great. just make sure the listener is configured for *.crmonline.com and make sure all the request for the * goes to the CRM4 server. And make sure you configure “Requests appear to come from the orginal client” is ISA, to make sure the Hostheader stays intact.

When IFD (Inter facing Deployment) is enabled you must understand a ISAPI filter is added towards IIS, and this ISAPI filter is making redirects towards the Form-based Authentication. When you’re using provisioning, the webservice on the CRM4 Server is also “proctected” by the ISAPI filter. So when you call the webservice – http://localhost/MSCRMServices/2007/CrmServiceWsdl.aspx you’ll notice a redirect towards the IFD url https://{defautlinstance}.crmonline.com.

When start IFD, you will see you can add IP-Ranges. It took me some time to understand, but those ranges are just making sure the ISAPI filter won’t react when you coming from that specific url defined in IFD.

So for example, you’re provisioning server is 10.10.1.10, make sure you add the 10.10.1.10 address in IFD so basic autentication is active again.

1. You can let a software supplier connect towards an environment where other customers or partners are running.
2. You can guarantee the customers data integrity
3. A custom make customization or additional service can potentially break the system.

So we choose the following options:
- A customer can host CRM on the SaaSplaza Multi-tenant CRM Environment. SaaSplaza will be responsible for the entire operation, and the system will be scaled for user demand.

- A partner can host CRM on his own Server where his customizations and verticals are installed. The partner is in that case also responsible for the CRM. Every partner that’s active on mySaaSplaza can decide if he wants to automatically deploy CRM on the SaaSplaza CRM environment of on the Partner CRM environment. With an easy dropdown list the Partner can decide where the customer should be located.

SaaSplaza is an open Platform that brings software suppliers and implementation partners together for the transparent supply of Software-as-a-Service.

This unique system benefits end-user organisations by presenting them with a wide choice of different SaaS solutions, all delivered from one open Platform.
This high quality platform is further supported by superior levels of service and presents the possibility for easy data integration.