When a company goes through the trouble of creating and publishing a Press Release about you joining the team, I suspect that they expect some work out of you. So off to work I go!
I get a lot of questions about using the Windows based Hosting Solution 2.0 (this is also included in the latest solution, "Hosted Exchange 2003.1"), to enable shared web hosting. The most common question is, "Can the Windows based Hosting Solution 2.0 do shared web hosting?" Well, the simple answer is Yes. But its followed by, "it can do shared web hosting, but it doesn't to it out of the box". Now the confusing part is the can statement. This is because the HE 2003.1 solution provides an IIS (6) Provider and SQL Admin Provider that enables the creation of websites on IIS 6 and SQL Databases on SQL 2000. The HE 2003.1 solution does provide the components to allow for shared hosting of web, SQL, and FrontPage via MPS via the providers mentioned above, but there is a lack of namespaces and a web user interface that integrates the entire experience. (The debate about a web UI is a long running one. I'll tackle that topic later.)
Many hosters that have only 5-20 servers in their "data center" do not have a sophisticated User Interface already in production. In order for them to leverage the power of Windows, they need a web based user interface to allow customers to manage and attend to their own services. Currently, there is no web based user interface that uses all, and even extends, the features that ships with Windows based Hosting 2.0 or Hosted Exchange 2003.1. Even if a customer purchases Ensim, they will be using many of the Ensim defined setting for creation of websites and mailboxes and not what was provided with the solution. This may change in the future, but this is the current state as it pertains to MPS and the namespaces.
Also, the HE 2003.1 solution does not contain a provider for Windows Sharepoint Services (WSS) provisioning. Although the solution team did develop a provider for WSS, it has not been released via a solution or outside of a solution (even if they did give it to out, it would need to be supported or release the IP so we could customize by an SI for customers)
So here is a quick rundown of the issues as to why the current solutions provided by the CS team does not enable a quick to product shared web hosting platform:
- No production ready web user interface for delegated administration for user, web, and database management
- No MPF namespace that provisions IIS 6 websites using the latest IIS provider and the best practices for delivering web hosting on Windows 2003
- No Resource Manager for IIS 6 or Shared SQL
- No administration tools to manage customer websites and resources
- No user quotas (Some customers maybe restricted to a number of user accounts. This relates more towards WSS and Exchange)
An alternative is using the Shared Web Hosting Deployment Guide. It provides a "How To" on using Active Directory, IIS 6, SQL, ASP.NET, FrontPage, and Windows Server 2003 POP3 Email for using in a Shared Hosting Scenario. It even includes a number of scripts, but this would not be suitable for customers that want to use MPS for Shared Hosting. It would also not be suitable for customers that wanted to delegate administration to customers. This is because the scripts need to be executed by a Service Provider administrator. And finally, even if a customer wanted to use this guide as a basis for deploying Microsoft products for use as a web hosting platform, the would still need to pay an SI to integrate the scrips in such a way that allowed them to go into production.
Finally, if a customer is looking to implement the WbH 2.0 (Actually HE 2003.1 is the updated version of the WbH 2.0 deliverables), they would need to hire a Systems Integrator (eQuest having a number of clients that have gone this route already) to provide additional software integration components to enable what was missing (listed above) in the solution. Now this isn't saying that these (WbH 2.0 & HE 2003.1) solutions does a poor job for Shared Hosting of IIS 6, WSS, and SQL, but it was simply not the focus for those solutions. WbH 2.0 was focused on Dedicated Hosting (using a shared infrastructure (AD, MOM, & SMS)) and HE 2003.1 was focused on Hosted Exchange (Yes Shared, but focused on hosting 10k GALS. This would be outside of the scope for smaller hosters).
Now I must point out, there is a namespace named “Rainier Dedicated IIS” namespace, but it was only intended for use as a sample and is only used by the Rainier Sample WebPages (Rainier was the code name for the Windows based Hosting Solution 2.0). The testing of it was also pretty light. The namespace has one core method that will perform the following functions:
- Create a new organization (AD OU)
- Create a new AD User
- Add the new user into the organizations Admin group
- Create the site directory structure – This method uses the IIS Site Namespace
- Create the IIS (6) website
- Enable Frontpage
One thing to point out is that these namespaces don’t support the creation of a website based on a UNC path. What this means is that you can only create sites where the content is stored locally. Now it's not a HUGE deal to add in this functionality, but it further displays why the solution isn't an "out of the box" package for shared web hosting.
Finally, the solution does not have an updated Resource Manager for IIS 6, SQL, or WSS. The solution also does not have a provider for WSS and neglects to provide a web based user interface to enable delegated administration to end customers. All of the pieces would need to be developed by each customer when deciding to leverage the solution. The HE 2003.1 solution does provide information for hosting WSS, but does not include a provider or namespace for WSS hosting. It does have a script embedded into the planning document, but this would not be sufficient to integrate into the rest of the solution components for production use.
Now I know I'm making this sound kind of bad, but I'm really not. After all, I was the PM that drove this so I should know what it lacks. Hey, even I can admit that my "baby" is ugly (not my real baby, because he's beautiful :) ) As I previously stated, the solution was focused on dedicated shared web hosting and it wasn't meant to be "self deployed" but was instead focused on providing a best practice for consultants to use during their customer deployments. The Windows based Hosting Solution/Hosted Exchange 2003 Solution, provides many of the tools and guidance for delivering a world class shard web hosting platform, but there are still many integration pieces that need to be development prior to going into production.
Now as I understand it, the next set of solutions will provide a lot more capability in the Resource Managers, WSS Provisioning, etc. I hope to have more updates on that soon.
Conrad Agramont, Senior Architect, eQuest Technologies, email@example.com
In a previous blog posting of mine ("Service Providers: Public Folders vs. Windows Sharepoint Services") I described my thought of having Sharepont Services replacing Public Folders. Well it seems that someone in HP has the same vision. There is a Microsoft Webcast ("TechNet Webcast: Migrating eRooms, Windows File Services and Exchange Public Folders to SharePoint - Level 300") that discusses this exact topic, but is focused on the Enterprise.
I guess it's true, great minds think alike!
Description of the web cast:
“A challenge for any enterprise is to ensure that its people are connected to the right information in order to collaborate effectively. In many cases legacy content repositories already exist and accumulate valuable information into knowledge silos. Microsoft® SharePoint™ Products and Technologies provide the next generation collaborative services for today’s information workers. Learn from practical experience how to approach migrations from legacy platforms to SharePoint Products and Technologies. Join this webcast to learn how to reduce cost, provide new capabilities and harvest your information assets to their fullest with a move to SharePoint Products and Technologies.”
OK, so the webcast really isn't about “Replacing”, but more of keeping you existing stores, but just porting the content into Sharepoint (probably Portal). But isn't that just one step away from replacing those stores? Gosh, I hope so.
So because of the headaches of Exchange Public Folders and being able to have remote public shares available from a hoster (sure you COULD do this, but the headache and cost isn't worth it), shouldn't we just start planning WSS it be THE method of storing your documents on the web. After all, isn't that why WSS is a free add-on to Windows?
During a conversation with Paul Edlund (eQuest), we brought up the topic of the hassles of providing Exchange Public Folders as apart of a Hosted Exchange service offering. Public Folder provisioning (via WebDAV), quota management (Each folder in a PF gets the same quota size as the parent), and security is such a pain in a hosted environment. The Microsoft Hosted Exchange 2003 Solution provides a lot of “workarounds“ that makes Hosting Exchange 2003 as a service, including Public Folder, much easier. But it still doesn't remove the pains found in Exchange (especially public folders) any less annoying.
So my thought is, why not just give customers a Windows Sharepoint Services (WSS) site instead? OK, WSS has it's own set of challenges, but the overall additional functionality is so much better than a Public Folder. As Paul pointed out to me, you can't just drag and drop an email into a Sharepoint site as you can with a Public Folder. OK, I'll accept that as a limitation.
I think the big hold back is integration. Public Folders are right there in Outlook. So the learning curve of where to go is reduced because of its convenience in location and the UI is the same UI as Outlook. I think this can be overcome a bit today. I have some thoughts, but not willing to give my “secrets“ away just yet. ;)
I think in the long run, the Outlook team should think about making Sharepoint sites integrate into Outlook as if it were a “Public Folder.”
Conrad Agramont, Senior Architect, eQuest Technologies, firstname.lastname@example.org
In doing some additional research on Exchange 2003, I ran across this posting on the Exchange Team Blog. It's the Exchange OWA Admin Tool. I haven't used it yet, but will be toying with it today. I'll give my thoughts later.
Time for a more personal post...
This past week, I was pointed towards 2 DVD's that have added some joy to my life.
red vs blue - http://www.redvsblue.com/estore_dvds.shtml (Thanks Bill)
They're animated (red vs. blue...kind of) and funny. If you're into that sort of thing.
So, I'm doing some research into Windows SharePoint Services (WSS) and ran across this website:
I'm not sure how long this has been available, but I thought it was pretty handy.
You know whenever I think about Identity Management, I always think of a big political and technology mess. I'm sure many others do too. For if there wasn't an Identity Management mess, we wouldn't have products and technologies like Identity Integration Server (Microsoft), Java System Identity Manager (Sun), WS-Federation, SiteMinder (Netegrity), COREid (Oblix), and many more.
Why has it come to this? Well I think it comes from the general chaos of software development. Every time we write a new piece of software, we always seem to introduce a new primary key (please excuse my SQL lingo) to identify a unique identity. From there, the beginning of our ID management nightmare begins. The nightmare only get more intense when we need to link/sync/etc. identities from one system with another. This is why products and technologies listed above are created to help sort the whole thing out, but make no mistake that using an off the shelf product or technology is only part of the answer. This is because, by the time an organization thought it was important enough to invest in an identity management solution, the mess has already gotten out of control.
The mess that I refer to isn't just the numerous systems that contain identities (not all of them unique either) or even the varies platforms, protocols, and API's needed to access that information. I'm referring to the number of organizations and politics that "own" pieces of the data. Day to day business decisions, boundaries, and politics seems to be the biggest barrier to getting an identity management solution executed. And it's not just because some people can't let go of their control of the data (but it IS a big part of it), but it's also because there isn't anyone (or team) with the organization that know where all the data is or who owns the data (and why they own it).
Now, even once you fight through all of the political and business issues, there still is the large task of choosing the right technology strategy to implement. Each technology has it's pro's and con's, but they have something in common: System Integrators. This is due to the fact that you can't just drop an Identity Management product in on day one and link all of your back-end systems, and perhaps external data (e.g. outsourced payroll systems), with little to know integration. Sure, an organization may have some talented developers and engineers, but do you really want to focus them on fixing your Identity Management problem when they could be developing new solutions to drive business? Ya, I didn't think so. So this is where an SI with the expertise to connect your system together. But even this is just another small baby step.
In order to best leverage your investment, all new third party products that are purchased should integrate into your environment by the time the service is put into production. This will remove, or at least greatly decrease, the integration/migration woes when connecting with your now existing Identity Management (IdM) solution. But this is not likely to happen. Why? By the time the IdM solution is in place, it has become an important part of the core back end system processing. Which also means that we have now centralized the IdM solution. To be as kind as possible, we've just made a new king or committee that "Safe-Guards" the system. Hence, we've just created a new bureaucracy.
So now, a local IT person deploys a new software package (off the shelf product, custom software, etc.), it becomes popular, and when it reaches to the point where it now needs to integrate with the IdM solution, it's now time to place another call to your System Integrator. Even when an organization has an IdM solution, there will always be applications that are created and deployed without the IdM in mind.
There are a few things that could have made this scenario a bit easier.
- What if the product shipped with a "plug-in" to a given IdM Product? That sounds great if there was only one IdM product on the planet (I know my friend at Microsoft are hard at work on this one :) ). But with so many vendors, I think Software Product companies are staying away from investing in this right now.
- Perhaps another Industry Standard? Perhaps this could be a solution, but
- Keep your favorite Systems Integrator (eQuest) on speed dial. This is today's Status Quo, but without the above options really being implemented throughout the industry TODAY, this is really the only option available.
So, if you're starting to see that your organization might have an Identity Management issue, you probably already have one. (Another shameless plug coming) When you call your System Integration , like eQuest Technologies (there it was), you should keep in mind that you'll need to have many of your business issues worked out prior to picking the right technology. This can either be done before or with your SI.
Conrad's stream of conscious is now over (lucky you!). More later...
Conrad Agramont, Senior Architect, eQuest Technologies, email@example.com