The second tip is distribution lists, which are also kind of an important thing to get set up. To do this, you need to craft a CreateDistributionList XML request—this is just an XML file that looks like:
<request>
<data>
<container>LDAP Path</container>
<preferredDomainController>Domain Controller</preferredDomainController>
<managedBy>List Owner</managedBy>
<name>List Name</name>
</data>
<procedure>
<execute namespace="Hosted Email 2007" procedure="CreateDistributionList" impersonate="1">
<before source="data" destination="executeData" mode="merge" />
<after source="executeData" destination="data" mode="merge" />
</execute>
</procedure>
</request>
Sample:
<request>
<data>
<container>LDAP://OU=MyCustomer,OU=MyReseller,OU=Hosting,DC=litware,DC=local</container>
<preferredDomainController>srv01</preferredDomainController>
<managedBy>frank@test.com</managedBy>
<name>Triage</name>
</data>
<procedure>
<execute namespace="Hosted Email 2007" procedure="CreateDistributionList" impersonate="1">
<before source="data" destination="executeData" mode="merge" />
<after source="executeData" destination="data" mode="merge" />
</execute>
</procedure>
</request>
You can then run that on your HMC server using the provtest command. So how do you manage who is actually in the list? Well, this is actually very easy, thanks to Outlook. First, just open an email and type the list name into the line, then right-click and select Properties:
You can then use the Modify Members button to add or remove members of this list.
Note: This can only be done by the list owner, which you specified when you created the list in the managedBy node.
First of a new series, but this is more a mini-series (just three parts). It is just a follow-up to the last series Zen of Hosting, so it focuses on a few tips for working with HMC. All this series is from HMC 4.0, so on 4.5, your mileage may vary.
The first part is how to add a room—because meeting scheduling is kind of important. To do that, first add a user via the normal UI (i.e., the web portal). From this point, it’s actually normal stuff for adding a room:
- Go into AD Users and Groups and disable the user.
- Then go into the Exchange Management Console and add a room to your existing (disabled) user.
- Viola, done.
The GAL and other Exchange/AD stuff is maintained because the user was added via the HMC way.
For a consistent environment, you need naming standards, but the idea of a standard is universal adherence—and in IT, there is no such thing. The first thing I looked at was a naming standard for the servers themselves. Thankfully, Microsoft has published recommendations on this (available here), which we decided to follow since it is simple and easy to use and remember.
Microsoft’s published recommended naming convention is aa-bbb-ccccc-dd. The definition of the format is:
aa is the country code,bbb is the city designation,ccccc is the server role,dd is the server number.
If the server is part of a cluster, array, or similar, the last two characters of the server role indicate which cluster it belongs to.
Samples:
The first domain controller in Redmond, USA, would be: us-rmd-ad-01
- us = USA
- rmd = Redmond
- ad = Active Directory
- 01 = First Server
The first BizTalk server in the second BizTalk cluster in Cape Town, South Africa, would be: za-cpt-bts02-01
- za = South Africa
- cpt = Cape Town
- bts02 = BizTalk Cluster 2
- 01 = First Server
The first MSCRM server in Auckland, New Zealand, would be: nz-ack-crm-01
- nz = New Zealand
- ack = Auckland
- crm = MSCRM (corrected from infr)
- 01 = First Server
However, this is the only published naming standard I could find, so the naming for databases, ISA rules, etc. have all been developed internally—I can’t disclose those.
This also brings to an end this series on HMC hosting. But fear not—I have a quick 3-part mini-series on the top 3 tips for managing a HMC environment to keep busy with.
So if you are installing a Windows Server 2003 machine as a Hyper-V machine, you will find out you need to install Service Pack 2 prior to installing the integration components (this is the software that increases performance, improves mouse functionality, etc.). Besides inserting a DVD and accessing it, there aren’t many other options, since the network card configured by default doesn’t work until the integration components are installed.
The solution is to remove that network card and add a Legacy Network Adapter under the Add Hardware section.
This network card works regardless of whether the integration components are installed, but it is not as fast. So once you’re up and running, don’t forget to revert it back.
So in Vista and/or IE8, there seems to be an issue with CHM files that you have downloaded from the Internet—they simply refuse to load their content.
I encountered this while trying to open the HMC 4.5 documentation, which was, as you might have guessed, provided as CHM help files.
To fix this:
- Close the file.
- Right-click it and select Properties.
- In the bottom-right corner, you’ll find the Unblock checkbox—enable it.
- Click Apply, then OK.
- Now you can use the file normally.
The last of the hurdles to overcome for deployment was the running of the DNS server. This was because we ran on a private IP range internally and used ISA to match external IP addresses and ports to the services we wanted to publish (i.e., NAT). This essentially allowed us to lower the attack surface, as we only exposed what was needed, and also enabled us to mix and match servers to the same IP—thereby reducing our IP address usage.
This setup also meant that we needed not only DNS servers to help internal servers and staff locate other servers and services but also external servers to allow users on the "big bad" Internet to find them. There was so much duplication of work in this configuration deployment scenario, as you had to create records on a best-case scenario of two servers and, in the worst case, four servers—and configure them differently. This also increased the area for mistakes considerably. The upside was that internal staff did not need to leave the LAN and return via the Internet or even go through the external firewalls. We could also use different domain names internally and externally, which was great for testing and development and only publishing when needed.
What I do not understand is why the DNS server team at Microsoft cannot take a leaf from MSCRM 4.0's IFD deployment and allow you to specify what the internal IP range is while also letting you set A/CNAME records for both internal and external IP ranges. This way, when an internal IP requests resolution, it returns the internal A/CNAME records, and for non-internal requests, it returns the external A/CNAME record. This is such a logical feature that Bind has offered for ages—so come on, Microsoft, steal another idea from Linux😉
One of the design choices for the DNS structure was a concept of mine called IP address abstraction. The idea of DNS is to abstract away IPs, but in normal configurations, you end up with loads of A records—and the moment you need to change IPs, you spend days updating them across all records. IP address abstraction means taking a core domain name and creating a single A record for each IP you have.
Examples:
internal1.test.com A 192.168.0.1internal2.test.com A 192.168.0.2
Then, everywhere else, you use CNAMEs pointing to those names, regardless of the domain.
Example:
[www.sadev.co.za](https://www.sadev.co.za) CNAME internal1.test.comsadev.co.za MX 10 internal2.test.com[www.test.com](https://www.test.com) CNAME internal1.test.com
The advantage is that if the IPs ever change, you update them in one place, and the change reflects everywhere—yet the end-user experience remains exactly the same as with traditional DNS.
Since we had Windows 2008, we just had to try out Core Edition, which is the version of Windows where Microsoft promised everything would be command-line-based. I like to think of it this way: if Vista stole the UI from Apple’s Mac, then Win2k8 tried to steal it from Linux...
So before I get into Core, let me first state that Win2k8 is the best server OS Microsoft has ever released. It’s amazing how well-polished everything is, and the tools included are great. Does it compare to Linux servers? Well, in some places it kicks ass, and in others, it doesn’t—but since Linux servers are the de facto standard for command-line-based systems, if we compare the command-line features, Microsoft has done a horrible job.
All that’s actually happening is you get the normal command prompt in Windows, and they dropped Explorer.exe from being the shell. In fact, Explorer.exe doesn’t even get installed—but a lot of our old favorites are still there, like Ctrl+Alt+Del, which still brings up the usual menu, and Task Manager still works.
Microsoft dropped so much that the gain in RAM is impressive (our average RAM usage normally is 750 MB, but on Core, it’s a mere 300 MB). The attack surface and patch requirements have also shrunken significantly.
Getting back to command.com as the shell—that’s likely the biggest single mistake of Core. It’s not like Microsoft doesn’t have a great command-line system, like PowerShell, which they could have used instead. In fact, there’s so little added to the command line that after this experience, I went back to a Win2k3 machine and was able to do most of this anyway—and it’s not hard to kill Explorer.exe as the shell in Win2k3. One advantage of doing this Core mockup on 2k3 is that at least Internet Explorer is there for you to get online for help. But in Win2k8 Core, there’s no decent help—just the same old crappy command.com stuff.
Linux has man pages, PowerShell has Get-Help, but the console has… thank the heavens that I was able to use my laptop to get online. For example, I had problems with the first two Core boxes trying to run Hyper-V on them—it just gave all kinds of RPC issues. Turns out, even though I hadn’t set the DNS correctly using netsh, I had set it for Primary Only instead of Both. What the difference is, I don’t know—because using the Windows GUI to set network settings for the last 20 years obviously gets this right. Why make it so much tougher?
Another interesting feature of Core—something I never had to worry about until I attended Win2k8 IIS training that Microsoft ran—is that in Core, you can’t run ASP.NET for websites, because Core doesn’t have the .NET Framework. This is because the .NET Framework installer requires a GUI. I suspect this is the same reason PowerShell can’t be used either, since it’s .NET-based. But here’s what I don’t understand: THERE IS A FRIGGING GUI—it’s all around the command-prompt window!
My recommendation is to avoid Core—the extra work doesn’t make up for the cost of a little extra RAM. Instead, spend less time setting up the server and more time billing customers—just buy more RAM. Hopefully, Windows Server vNext gets it right.
As I approach the end of this series, I want to highlight some of the technology that the hosting machine is built on and some of the experiences I learned with that. These last few posts are much shorter than the earlier ones but hopefully provide some quick bite-sized info.
So if you have looked at standard HMC, then add all the technology we have added to it, you would assume there is a building full of servers. The reality is the server room has got lots of space and isn’t that big. How did we achieve this? Slow applications because we are running everything on fewer servers? Not at all.
We bought some seriously powerful HP machines, loaded them with a ton of RAM, and installed Windows 2008; but how does that help with running lots of systems? And doesn’t HMC break if it runs on Win2k8 (see way back to part 2)? Well, Win2k8 has the best virtualization technology Microsoft has ever developed, named Hyper-V. This is seriously cool stuff—in that it actually runs before Windows starts and virtualizes Windows completely (rather than running virtual machines on an OS, they run next to it). The performance compared to Virtual Server is not even worth talking about; it basically pushes Virtual Server into the stone age.
It is very fast and seems to handle the randomness of the servers’ usage (those little spikes when you run multiple machines on one piece of hardware) so well. But not everything is virtualized: there is a monster of an active-active SQL Server cluster (since so much needs SQL), and we have a number of oddities, such as the box which does media streaming—due to the fact that some specialized hardware can’t be used in a virtual machine. A worry for when we started with Hyper-V was its beta/RC status... Well, with thousands of hours of uptime logged so far by servers on it, it has been ROCK-solid.
I can now officially let out one of my many secrets, which is that I am speaking at Tech-Ed Africa this year! Oddly enough, I’ll be speaking about something I’ve never blogged about—WPF and building business applications with it. I’ll be co-speaking with a good friend, Simon (from Blacklight), who is an amazing designer. It’ll be a very fun talk. For more details, see the Tech-Ed Africa site.
For this instalment, the product I am going to cover is Microsoft Dynamics GP, which is very interesting compared to MS CRM (part 6) and MOSS (part 7)—in that it is not web-based and thus presents a completely new challenge when exposing it in a web-based hosting environment.
For those who don’t know the architecture, it is a Windows Forms application (not sure if it’s .NET or WinAPI, but the GUI is a thin veil over a monster SQL database with so many tables and stored procedures, it’s scary). The normal way is that the user gets this client installed, and the client directly connects to the SQL server. So if you are thinking of hosting and end up having to allow direct connections over the web to SQL, think again—the security risk of this makes it a huge no.
After spending some time investigating other people offering hosted GP, the solution everyone else seems to provide is: give you a server and let you remote in via Citrix. As this is a Microsoft end-to-end solution, Citrix is not an option, but Microsoft does have Terminal Services (TS), which can compete—and in Windows Server 2008, it competes better than before. TS has always been about connecting to a full session, which is nice, but we don’t want nice—we want amazing.
So, with Windows Server 2008, TS includes a feature called Remote Applications. Remote Apps lets an admin publish an application to a user, so it runs from:
- A special icon,
- An MSI file (which you could deploy using AD or System Centre), or
- From a website.
It looks just like it’s running on the user’s machine, but in the background, it spawns a normal TS session on the server, starts the application, and pushes only the UI of the application to the user. It’s great—the user thinks it’s on their machine—and it’s super fast (thanks to the server’s power), and it’s not fighting for resources on the client machine.
As this is the first version of this, there are still some rough edges that need addressing. Firstly, the application still runs on the server, so if you go File → Open, you browse the server’s file system. (I know TS can share drives from client to host, but they look like other drives—not the normal C, D, etc. users expect.) What should happen is that the admin should be able to disable the server’s drives from being exposed, so only the client’s drives are shown. The same should apply to printers.
One advantage for GP is that working with the file system isn’t a big requirement, but printing is, and that’s less of a pain. The next area is security—it’s still launching a TS session, which means if you want to allow a user to run a remote application, they end up needing login rights. (I understand the technical requirements around this, but there should be a way to separate people who will log in via TS to the machine and those who just need Remote Apps on the terminal service level.)
Despite these challenges, Microsoft Dynamics GP looked like it was going to be difficult to deploy—but in the end, it was very easy.
