MSDN
How to specify internal and external servers for Live Meeting with OCS 2007?
OCS 2007 (Office Communications Server 2007), which was just released to RTM, finally has Live Meeting Conferencing built-in. You can use the Live Meeting client or the web frontend to attend your meetings. Because of the nature of OCS, you can deploy all services internally and expose selected services to external users (even for federated users) through your DMZ.
The challenge here is that when you deploy Live Meeting client centrally through SMS or Active Directory, you would need to specify what is the internal server for LAN users, and what is the external server for roaming users. Actually there’s a switch for that in the GPO template but it only affects Office Communicator 2007 client, not Live Meeting.
So here’s the fix:
Specify the values in registry:
HKEY_CURRENT_USER\Software\Microsoft\Shared\UcClient\ServerAddressExternal
HKEY_CURRENT_USER\Software\Microsoft\Shared\UcClient\ServerAddressInternal
Leech these to your GPO, and roll it out to your client workstations - works like a toilet in the train (bad Finnish humor, I know)!
Upgrading your existing MCSE certification to Windows Server 2008
I’ve been waiting ages to get my existing Windows Server 2003 MCSE-certification upgraded to more recent technologies. Now that we have Windows Server 2008 in the horizon it’s nice to see that Microsoft Learning has the following exam in beta: Upgrading Your MCSE on Windows Server 2003 to Windows Server 2008, Technology Specialist: http://www.microsoft.com/learning/exams/70-649.mspx
You can get a clearer picture what you need to achieve here: http://www.microsoft.com/learning/mcp/mcse/windowsserver2008/default.mspx. Notice that since Powershell is an integral part with Windows Server 2008, it’s time to brushen up those skills from Windows Script Host (WSH) to PS! And don’t forget IIS 7.0. Or .NET Framework. Or the new Server Core-roles.
“Requested registry access is not allowed” error with Forms Server and/or MOSS
I bumped into this error message with a customer MOSS + Forms Server installation, that had it’s key recently upgraded to an enterprise RTM version from a Beta 2 Technical Refresh (B2TR) key. Upon opening InfoPath-forms via Forms Server users would get a “Requested registry access is not allowed” -error.
After playing around a bit with the problem, and using regmon (http://www.microsoft.com/technet/sysinternals/utilities/regmon.mspx), I found out it was a security-related problem with this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\OfficeServerPremium
To fix this, I added WSS_WPG and WSS_ADMIN_WPG with the following permissions for those keys:
WSS_WPG (read), WSS_ADMIN_WPG (Full Control)
Implementing single sign-on (SSO) with MOSS 2007
I needed to build up MOSS 2007 portal that would integrate some of the existing Line Of Business (LOB) applications. We also needed to use SSO, because some of the applications weren’t AD-enabled. To use SSO, you can create your own custom web part and connect to the SSO services through there.
Enabling SSO
To enable SSO, you need to start the Microsoft Single Sign-On Service in the Services-tool of Windows. You can also do this on the command-line with “net start ssosrv“. Keep in mind the service needs to run under an account that has access to the SQL hosting your SSO database. For demonstrational purposes you can use administrator, otherwise create a dedicated account.
Next, go to MOSS Central Admin at http://localhost:port, where port is whatever you specified when installing MOSS. Select Operations-tab, and navigate to Manage settings for single sign-on. If you get this error:
Failed to connect to Microsoft Single Sign-on Service. To configure, please ensure the service is running.
It means your SSO service is not running. Go and doublecheck the settings on that. Then, select Manage server settings, and fill out the fields. Default values are normally ok for those fields that have been prepopulated. Click OK - the database and settings for your SSO service should now be created.
Configuring applications for SSO
Now that you have SSO running, you need to configure which applications are going to take advantage of it. Go to Manage settings for enterprise application definitions (http://localhost:port/_admin/sso/ManageApps.aspx) and click New Item. Enter a display name, application name and contact email address. The important thing here is to enter an application name that is easy to remember and describes the integrated application, such as “Asp3Tools” or “FinanceApp”. Fill out rest of the fields as you see fit.
If you’re wondering what the five fields under logon account information are for, you can use those to send a maximum of 5 custom fields to your LOB application upon user authentication. Normally you’d use 2, one for username and one for password. MOSS uses these field names and settings to render the authentication form dynamically for you, when logging into the the LOB application for the first time (via SSO).
Creating skeleton web part for SSO
Now that you’ve successfully configured SSO for MOSS, it’s time to create your web part. I’ll provide the basic RenderContents() -method for you that walks through the basic step when using SSO:
protected override void RenderContents(HtmlTextWriter output)
{
string[] rgGetCredentialData = null;
try
{
Credentials.GetCredentials(1, “AppName“, ref rgGetCredentialData);
ISsoProvider provider = SsoProviderFactory.GetSsoProvider();
SsoCredentials creds = provider.GetCredentials(”AppName“);
creds.Evidence = new System.Security.SecureString[2];
try
{
// your implementation of accessing the LOB app
}
catch (Exception e)
{
// catch exceptions
}
}
catch (SingleSignonException ssoex)
{
if (SSOReturnCodes.SSO_E_CREDS_NOT_FOUND == ssoex.LastErrorCode)
{
string strSSOLogonFormUrl = SingleSignonLocator.GetCredentialEntryUrl(”AppName“);
output.Write(”<a href=” + strSSOLogonFormUrl + “>Click here to save your credentials for the Enterprise Application.</a>”);
}
}
You can do a HttpWebRequest to your application, parse the HttpWebResponse and render out your application. The important thing is to use the correct application name (AppName) and catch the SSO_E_CREDS_NOT_FOUND exception for first time users. MOSS will then create the initial authentication page for you, hiding possible other authentication pages you have in your LOB system.