IIW Model Support

IIW Tenant Customer Types and Service plan

To support the IIW model, Hosted Messaging and Collaboration version 4.5 adds two customer types “IIWResellerOrg” and “IIWTenantOrg”, and also adds one customer service plan “IIWPlan”.

Simplified Model based on the Current Business Model

With IIW model added for provisioning, in Managed Active Directory::GetPolicy procedure, we remove the legacy MultiGroup container whose contents provide a smaller AD footprint for representing both hosted businesses model and consumer model. The MultiGroup container is only for some legacy support in Windows 2000 or previous Operating Systems. It is actually no longer existed in Windows 2003 and beyond. By removing this container, all new organizations are created without the overhead of this additional OU structure.

Active Directory Services Update

Active Directory services update includes the following operations.

IIW Reseller Org creation
IIW Tenant Org creation
Other helper features

If you want to experience IIW features, “IIW Reseller Org creation” is the starting point. Hosted Messaging and Collaboration version 4.5 provides a new procedure Hosted Active Directory::CreateIIWResellerOrganization. It is actually a wrapper of procedure Managed Active Directory::CreateOrganization. In addition, the CreateIIWResellerOrganization sets the organization’s Active Directory property businessCategory to “IIWReseller”, through which it could be distinguished from standard reseller. It also sets customerTypeCode in Database to “IR”, which stands for “IIWResellerOrg”. The policy applied to the IIW reseller is the same as that of a standard reseller.

Once an IIW reseller is created, IIW tenant organization can be created under that reseller. We provide a new procedure Hosted Active Directory::CreateIIWTenant. It also wraps the procedure Managed Active Directory::CreateOrganization. In addition, CreateIIWTenant sets the organization’s Active Directory property businessCategory to “IIWTenant”. The procedure also sets customerTypeCode in Database to “IO” which stands for “IIWTenantOrg”. It subscribes the organization with “IIWPlan” customer service plan.

Visual Basic Note:
Notice that CreateIIWTenant creates not only a tenant organization but also an organization admin.

After an IIW reseller and an IIW tenant are created, customer records will be created in PlanManager dbo.Customers table

Procedure GetTenantRoot returns the domain name of the tenant organization object when you supply an Active Directory object’s LDAP path. It is a wrapper of Managed Active Directory::GetThisOrganizationRoot. This procedure mainly allows for easy abstraction of the Tenant OU from the user. This enables the ability that UI or higher level namespace can easily identify and act against the IIW tenant organization when supplied only the path of an IIW user object.

Procedure UserIsSelf is supplied a user object LDAP path or UPN. It checks whether the user who summits the request is the supplied user object (LDAP path or UPN which you provided in request). This procedure is intended to support a common requirement of control panels and self service portals. In particular, this procedure checks if the submitted SID is the same as the user sending this request. Submitted SID is set to securityContext/@trustee by default. But if you provide authentication/basic node in request, the submitted SID will be overridden by value authentication/basic/@username.

A sample request with authentication/basic node and trustee attribute is listed below:

	Copy Code
<request> <data> <user>LDAP://CN=Administrator,CN=Users, DC=hmc,DC=rtm</user> <preferredDomainController>HMCAD01.hmc.rtm</preferredDomainController> </data> <procedure> <execute namespace="Hosted Active Directory" procedure="UserIsSelf" impersonate="1"> <before source="data" destination="executeData" mode="merge" /> <after source="executeData" destination="data" mode="insert" /> </execute> </procedure> <context> <securityContext trustee=”hmc\Administrator”> <authentication> <basic username="hmc\Administrator" password="Pass1word" /> </authentication> </securityContext> </context> </request>

Copy Code

<request>
   <data>
	<user>LDAP://CN=Administrator,CN=Users, DC=hmc,DC=rtm</user>
	<preferredDomainController>HMCAD01.hmc.rtm</preferredDomainController>
   </data>
   <procedure>
	<execute namespace="Hosted Active Directory" procedure="UserIsSelf" impersonate="1">
		 <before source="data" destination="executeData" mode="merge" />
		 <after source="executeData" destination="data" mode="insert" />
	</execute>
   </procedure>
   <context>
	<securityContext trustee=”hmc\Administrator”>
		 <authentication>
			<basic username="hmc\Administrator" password="Pass1word" />
		 </authentication>
	</securityContext>
   </context>
</request>

Email Services Update

Email services update includes the following operations:

SMTP domain related update
Enable mail service for a tenant organization

The following three SMTP domain related public procedures are changed to support rollup of SMTP Domain ownership.

CreateSMTPDomain
DeleteSMTPDomain
GetSMTPDomain

If a reseller organization owns an SMTP domain, all Tenants of that reseller can also own that SMTP domain as an asset in the Managed Plans database. In previous version, you could only create SMTP domain either on reseller level or tenant level. With these changes, you could not only share a SMTP domain from Reseller but also create a vanity domain for your tenant organization.

This Hosted Email namespace procedure CreateSMTPDomain is modified to handle the scenario while creating SMTP domain for Tenant organization where the specified domainName has already been created as an accepted domain and is owned by the parent reseller organization. Here we provide a scenario matrix to make the behavior more clear.

CreateSMTPDomain Scenario Matrix

Scenario	Result
Domain does not exist in any organization. Create for Reseller/IIWReseller.	Reseller/IIWReseller is the owner. CustomerAsset is added
Domain does not exist in any organization. Create for BusinessOrg/IIWTenantOrg.	BusinessOrg/IIWTenantOrg is the owner. CustomerAsset is added.
Domain exists and owner is Reseller/IIWReseller. Create same domain for the Reseller/IIWReseller.	Owner is unchanged. Bypass the created CustomerAsset.
Domain exists and owner is Reseller/IIWReseller. Create same domain for a child BusinessOrg/IIWTenant.	Owner is unchanged. CustomerAsset is added for the child organization.
Domain exists and owner is BusinessOrg/IIWTenant. Create same domain for the BusinessOrg/IIWTenant.	Owner is unchanged. Bypass the created CustomerAsset.
Domain exists and owner is BusinessOrg/IIWTenant. Create same domain for parent Reseller/IIWReseller.	Owner is unchanged. An error message is thrown from GetSMTPDomain.
Domain exists and owner is Reseller/IIWReseller. Create a vanity domain for child BusinessOrg/IIWTenant.	Reseller level domain owner is unchanged. Vanity domain’s owner is the BusinessOrg/IIWTenant.

Scenario

Result

Domain does not exist in any organization.

Create for Reseller/IIWReseller.

Reseller/IIWReseller is the owner.

CustomerAsset is added

Domain does not exist in any organization.

Create for BusinessOrg/IIWTenantOrg.

BusinessOrg/IIWTenantOrg is the owner.

CustomerAsset is added.

Domain exists and owner is Reseller/IIWReseller.

Create same domain for the Reseller/IIWReseller.

Owner is unchanged.

Bypass the created CustomerAsset.

Domain exists and owner is Reseller/IIWReseller.

Create same domain for a child BusinessOrg/IIWTenant.

Owner is unchanged.

CustomerAsset is added for the child organization.

Domain exists and owner is BusinessOrg/IIWTenant.

Create same domain for the BusinessOrg/IIWTenant.

Owner is unchanged.

Bypass the created CustomerAsset.

Domain exists and owner is BusinessOrg/IIWTenant.

Create same domain for parent Reseller/IIWReseller.

Owner is unchanged.

An error message is thrown from GetSMTPDomain.

Domain exists and owner is Reseller/IIWReseller.

Create a vanity domain for child BusinessOrg/IIWTenant.

Reseller level domain owner is unchanged.

Vanity domain’s owner is the BusinessOrg/IIWTenant.

The Hosted Email namespace procedure DeleteSMTPDomain is modified according to the CreateSMTPDomain change. A scenario matrix is shown in the following table:

DeleteSMTPDomain Scenario Matrix

Scenario	Result
Domain exists and owner is Reseller/IIWReseller. Get SMTP domain with Reseller/IIWReseller as the org.	Ownership is Reseller/IIWReseller
Domain exists and owner is Reseller/IIWReseller. Get SMTP domain with child BusinessOrg/IIWTenant as the org.	Ownership is BusinessOrg/IIWTenant
Domain exists and owner is BusinessOrg/IIWTenant. Get SMTP domain with BusinessOrg/IIWTenant as the org.	Ownership is BusinessOrg/IIWTenant
Domain exists and owner is BusinessOrg/IIWTenant. Get SMTP domain with parent Reseller/IIWReseller as the org.	An error message such as “The organization does not own the SMTP Domain with the name {SMTPDomainName}” is thrown

Procedure MailEnableTenant helps to enable a tenant organization for Hosted Email Services. In this procedure, it batches three operations including subscribing Hosted Email Service, adding available plans and creating SMTP domain. In fact, this procedure is not only used for IIW organization but also business organizations. However, it does have some special handling abilities for the IIW organization, specifically the ability to identify parent organization from a user path (GetTenantRoot is called if provided a user path instead of an organization path in MailEnableTenant request), in order to subscribe the appropriate object.

Inside procedure MailEnableTenant, it calls Hosted Active Directory::GetTenantRoot to get the owning organization LDAP path for mail service enable and then subscribe with the organization plan name, add available user plans and create a SMTP domain for the tenant organization. Then the tenant organization can use mail service. You can create the mailbox for the users under the tenant organization using the added available user plan. The tenant organization’s users can also use OWA features.

Unauthenticated Sign up for IIW

IIWSignup Procedure IIWSignup is modeled very closely to a legacy procedure BusinessSignup. IIWSignup creates an IIW Tenant Organization and Admin user as well as optionally generates a password and sends an email to a user alternate email address with the password. There is no explicit role check in this procedure. Actions are performed under the context of a privileged account. The account is already created and configured as an executeAS credential during Hosted Signup::Initialize. This procedure could be exposed through a Web Service that is configured to allow anonymous access. Customers are strongly encouraged to protect calls to this procedure using secured web services (locked down to only receive requests from a single source for example) as well as anti-scripting measures such as credit card validation implemented at the UI layer.

As indicated above, this feature is in place to support the development of Web Portals that allow for anonymous or unauthenticated sign up. There is a great deal of responsibility placed on the developer of the Web Portal to further secure this sign up process beyond the suggestions presented above.

Support Office Communication Service, Windows SharePoint Services and other future features

IIW model interacts with Hosted Messaging and Collaboration environment in much the same way as business model does. One primary difference is the active hours, with IIW users interacting with the system more after typical business hours. User can take advantage of any service on the platform including Office Communications Server 2007 Service, Windows SharePoint Services and even other future features. This may be the most important reason why we use IIW.