WEB HOST INDUSTRY REVIEW) -- The six-year effort to create a specific Web address for online adult entertainment has come to a close with the ICANN Board’s approval of the .xxx top-level domain.

According to the announcement from sponsoring registrar ICM Registry (www.icmregistry.com), this decision comes on the heels of an independent review that declared that ICANN’s previous decision to deny .xxx was wrong.

“It’s been a long time coming, but I’m excited about the fact that .xxx will soon become a reality,” ICM Registry chairman Stuart Lawley said in a statement. “This is great news." ICM Registry will now work with ICANN staff to complete the due diligence on its technical and financial qualifications and to finalize the contract to run .xxx.

In documents submitted to ICANN reported in a CNet news story, the ICM Registry proposed .xxx registry would charge $60 per domain name and let resellers add a markup in the ball park of $10 to $15 per domain. Secondly, the International Foundation For Online Responsibility (www.onlineresponsibility.org), a nonprofit organization, would be in charge of the rules for .xxx to make sure that issues surrounding child pornography, freedom of expression and the interests of the adult entertainment industry all weight in on the domain.

The ICM Registry expects .xxx domains to go live at the start of 2011, if not sooner. There are already 110,000 pre-reservations, which is expected to increase now that ICANN has formally approved the TLD.

According to the ICM Registry, the .xxx domain will provide a place online for adult entertainment providers and their service providers who want to be part of a voluntary, self-regulatory community. It will provide effective labeling of content, so that individuals and search engines know that .xxx websites likely contain adult content, which will allow for simple and effective filtering for those who wish to do so.

This will also provide an opportunity for domain registrars to sell millions of new domains, as well as effectively forcing them to buy a .xxx version of their current .com domain to maintain their brand

During the installation of Exchange rollup update for Exchange Server 2007 and Exchange Server 2010, some of the Exchange services e.g. the Microsoft Exchange Transport Service may fail to start. This issue occurs because there is a problem with the way in which the Exchange services interact with Forefront during the patching process. The problem is currently being investigated. However, a suggested workaround is to use a Windows PowerShell script to disable and enable the Forefront Service for Exchange during the installation.

A new feature was introduced in Exchange Server 2007 Service Pack 2 to allow administrator run PowerShell scripts during rollup installation. For more information, please refer to http://msexchangeteam.com/archive/2010/06/02/455063.aspx. The script in this article demonstrates how to use CustomPatchInstallerActions.ps1 file to disable and enable the Forefront service for Exchange utilizing this new feature. However the script can be customized by customers for use with other third party products in this way.

In order to allow installer to find the script file, these criteria must be followed:

1. The script file is named as CustomPatchInstallerActions.ps1

2. The script file is placed under <Exchange installation folder>\Scripts\Customization

3. The script file must have three sections:

• PrePatchInstallActions : User defined actions that will be performed before the installation starts.
• PostPatchInstallActions : User defined actions that will be performed after installation has finished.
• PatchRollbackActions : User defined actions that will be performed after rollback of the installation (due to cancellation of installation).

The details for each section are:

PrePatchInstallActions:

• Stop related services in this order:
  • MSExchangeSA
  • MSExchangeTransport
  • MSExchangeIS
  • FSCController
• Disable Forefront service by running "fscutility /disable"

PostPatchInstallActions:

• Enable Forefront service by running "fscutility /enable"
• Start related services in this order:
  • FSCController
  • MSExchangeSA
  • MSExchangeIS
  • MSExchangeTransport

PatchRollbackActions:

• The same as PostPatchInstallActions

A log file named CustomPatchInstallerActions.log will be generated under <SystemDrive>\ExchangeSetupLogs. It can be used to track failures generated during the execution.

NOTE: The script needs to be properly signed otherwise you need to run "Set-ExecutionPolicy Unrestricted" in order to run the script.

You can find the sample CustomPatchInstallerActions.ps1.template script HERE