Quote of the Month
The winner takes it all….The loser standing small.
The winner takes it all….The loser standing small.
The ISA Server Best Practices Analyzer (BPA) is a diagnostic tool that automatically performs specific tests on configuration data collected on the local ISA Server computer from the ISA Server hierarchy of administration COM objects, Windows Management Instrumentation (WMI) classes, the system registry, files on disk, and the Domain Name System (DNS) settings.
The resulting report details critical configuration issues, potential problems, and information about the local computer. By following the recommendations of the tool, administrators can achieve greater performance, scalability, reliability, and uptime.
The ISA Server Best Practices Analyzer is supplied with two supplemental tools.
• The ISA Data Packager enables you to create a single .cab file containing ISA Server diagnostic information that can be easily sent to Microsoft Product Support Services for analysis.
• BPA2Visio generates a Microsoft Office Visio® 2003 or Visio 2007 diagram of your network topology as seen from an ISA Server computer or any Windows computer based on output from the ISA Server Best Practices Analyzer Tool.
I faced problem in implementation Client Web Access server on windows 2003 R2 SP2.
The problem prevent client web access…first I thought it is configuration problem but when I checked the event viewer I saw that Error
ErrorID : 2274
Source : W3SVC-WP
This error on CWA server related to cwsauth.dll file that can’t be loaded.
I contact Microsoft for the error and got the following replay:
Office Communications Server 2007 supports the following tested 64-bit configurations:
Like you see it does not give any answer for my problem.. Actually deploying OCS in X64 bit system is not the best practice since the setup for OCS and the console run under the WOW64 subsystem since they are 32bit programs.
I searched the internet and find more problems related to this problem
Comment : Deploy your OCS server in win X86 mode..It is better.
Aside:Actually, I think your situation has a better solution that solve X64 problem. I think it is known issue with application running in IIS in WOW64 mode.
If you check your Event Log entries, you will likely find several of the following entry, followed by another entry declaring that the Application Pool is being disabled.
Description:
Could not load all ISAPI filters for site/service.
I think the reason why you are getting this event is straight forward:
What is happening when OCS wizard install .NET Framework 2 on IIS6 on 64bit Windows is that while IIS6 runs W3WP.EXE as 64bit, you are configuring it to load some 32bit ISAPI DLLs. This does not work and leads to the event log entry. Since the ISAPI DLLs are loaded for every request, this failure immediately happens again and again, thus triggering the “Rapid Fail Protection” health monitoring check of IIS6. This leads to this Application Pool being taken offline .
One way to fix this issue is to:
Changing IIS6 to run W3WP.EXE as 32bit allows the 32bit ISAPI DLLs installed by .NET Framework 2 for ASP.NET to load and run inside of it. This is done by running the following commandline:
This command switches IIS6 into running WOW64 (i.e. 32bit compatibility) mode on 64bit Windows on-the-fly so that IIS6 can immediately run 32bit ISAPI DLLs… unless that Application Pool is ALREADY returning 503 errors, in which case you MUST restart the Application Pool to have the bitness switch take effect. It makes sense because a 503 error means the Application Pool is offline and not running, so you must restart it to have setting changes take effect.
You can do this by either:
NET STOP W3SVC /y & NET START W3SVC
Now, I cannot guarantee that this works for you because you may have other applications that must run as 64bit, in which case you have a conflicting need to simultaneously run 32bit and 64bit code in IIS6, which is not allowed.
See KB 895976 for more details.

|
Note |
|
Windows Server 2008 does not include WebDAV by default, which is required for Configuration Manager 2007 management points and distribution points. For more information, see the release notes. |
What’s New in Configuration Manager 2007 R2 |
Automatic configuration allows Communicator to find and connect to the appropriate OCS server without manually entering a server name into its settings. Communicator has special requirements for DNS and certificates to make this work properly.
The problem that OCS likes other Microsoft UC solutions does not support multiple SIP name. Most of organizations need DNS splitting as security requirement.
Here you are the Scenario: We have organization that its internal domain name is Contoso.ad and have E2K3 server with E-mail Policy @contoso.com, they need to implement new OCS server to support internal and external users.
Easy, maybe it looks like that…The problem that office communicator is designed to log-on using server within same domain name i.e. the OCS FQDN must be in our case OCSSRV.contoso.ad.
Until now, it is okay but the user must log-on with name user@contoso.com so we have to support contoso.com SIP domain.
Are you confused? It is little tricky… here you are the solution
Split DNS configuration is a requirement for automatic configuration. Simply put, split DNS means you have two DNS zones for one domain name. One DNS zone exists on internal DNS servers and provides name resolution only for internal clients. Another DNS zone exists on external DNS servers to service external clients.
Split DNS is required so that users can use the same sign-on name in Communicator and have their correct login server resolved inside and outside the network.
First, we have to create primary DNS zone in internal domain with name Contoso.com. Create A record in it for OCSSRV server.
The following SRV records need to be created. Note that these records must be created in the DNS database of the servers authoritative for the particular zone.
|
Service Records (SRV) |
A Record |
IP Address |
|
_sipinternaltls._tcp.Contoso.ad |
OCSSRV.contoso.ad |
192.168.1.11 |
|
_sipinternaltls._tcp.Contoso.com |
OCSSRV.contoso.com |
192.168.1.11 |
Certificate Configuration
To support multiple domains for encrypted communications we require that all front-ends in the Pool be configured with a certificate. The certificate must match the FQDN returned by any DNS SRV query. Therefore, the certificate must contain multiple entries. We call these SANs (Subject Alternate Name) and the certificate must include the FQDN of the pool and one entry for each supported SIP domain.
Subject Name
OCSSRV.contoso.ad
Subject Alternate Name
Sip.contoso.ad
Sip.contoso.com
OCSSRV.contoso.com
OCSSRV.contoso.ad
I tried to do that through the OCS certificate configuration wizard …It should work.
but if it failed you can do it through another way.
You have to obtain Subject Alternative Name (SAN) to your OCS certificate. The OCS certificate is submitted to a certification authority (CA) that is configured on a Microsoft Windows Server 2003-based computer. The SAN lets you connect to a domain controller by using a Domain Name System (DNS) name other than the computer name. I will explain how to add SAN attributes to a certification request that is submitted to an enterprise CA (ContosoCA)
By default, a CA that is configured on a Windows Server 2003-based computer does not issue certificates that contain the SAN extension. If SAN entries are included in the certificate request, these entries are omitted from the issued certificate. To change this behavior, run the following commands at a command prompt on the server that runs the Certification Authority service.
Certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc
When you submit a certificate request to an enterprise CA, the certificate template must be configured to use the SAN in the request instead of using information from the Active Directory directory service.
To submit a certificate request that contains a SAN to an enterprise CA, follow these steps:
San:dns=OCSSRV.contoso.com&dns=sip.contoso.com
&dns=sip.contoso.ad&dns=OCSSRV.contoso.ad
Multiple DNS names are separated by an ampersand (&).
Now return to OCS deployment and choose configure certificate wizard,
Choose to assign existing certificate and choose OCSSRV.contoso.ad server authentication certificate.
Assign the certificate in the IIS and restart it.
Now you can sign in with user@contoso.com although your pool is OCSSRV.contoso.ad.
Check this also at the UC Guy
Blow The story of this great movement.
In our early days, all of Riseup’s servers were housed in people’s basements around Seattle. Though lovely in theory, in practice it meant that power outages, heat loving vermin shacking up with our boxes, and eco-conscious house guests turning off computers, could lead to collective panic. Our motto during this time was “Just as reliable as Hotmail.” We didn’t always know if we were doing the right thing spending so much time writing software, fixing bugs, and providing services, but we hoped it would grow and be good for the movement.
So here we are, seven years later, still hoping we are useful to people.
If you have any stories of how Riseup.net has affected your world, we would love to hear them, and might include a few in our newsletter this year. Please send them to pigeon@riseup.net.
Evaluating Windows Server 2008 software does not require product activation. Any edition of Windows Server 2008 may be installed without activation, and it may be evaluated for 60 days. Additionally, the 60-day evaluation period may be reset (re-armed) three times. This action extends the original 60-day evaluation period by up to 180 days for a total possible evaluation time of 240 days.
loadTOCNode(2, ‘moreinformation’); When the initial 60-day evaluation period nears its end, you can run the Slmgr.vbs script to reset the evaluation period. To do this, follow these steps:
| 1. | Click Start, and then click Command Prompt. |
| 2. | Type slmgr.vbs -dli, and then press ENTER to check the current status of your evaluation period. |
| 3. | To reset the evaluation period, type slmgr.vbs –rearm, and then press ENTER. |
| 4. | Restart the computer. |
This resets the evaluation period to 60 days.
After Long time of waiting Microsoft announce for Vista SP1 Beta Release.
Check this out.
One of the hardest thing in OCS 2007 implementation is certificate. It keep return errors all the time so you must be careful in every step in it.
While I was in OCS STD implementation I faced a event ID 36780.
I have tried installing multiple certificates, and am having issues with an Schannel event log error .I see the following errors in the event log:
Event Type: Error
Event Source: Schannel
Event Category: None
Event ID: 36870
Date: 12/27/2007
Time: 3:50:18 PM
User: N/A
Computer: OCSSRV
Description:
A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0×80090016.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
This problem occurs because of a limitation of the Certificates snap-in.
When you use the Certificates snap-in to copy a certificate together with a private key to the local computer store, the private key is not copied.
This happen when assign certificate you obtain to OCS ( Server Authentication ) to IIS to have secure SSL session.
To work around this problem, import the certificate together with the private key to the local computer store. To do this, follow these steps:
| a. | Expand Certificates (Local Computer), and then expand Personal. |
| b. | Right-click Certificates, click All Tasks, click Import, and then click Next. |
| c. | In the File name box, type the file name that you specified in step 2e, and then click Next. |
| d. | In the Password box, type the password that you specified in step 2d, and then click Next two times. |
| e. | Click Finish, and then click OK. |