Event ID 57 — AD CS Certificate Request (Enrollment) Processing

Event ID 57 — AD CS Certificate Request (Enrollment) Processing

Updated: July 8, 2009

Applies To: Windows Server 2008 R2

One of the primary functions of a certification authority (CA) is to evaluate certificate requests from clients and, if predefined criteria are met, issue certificates to those clients. In order for certificate enrollment to succeed, a number of elements must be in place before the request is submitted, including a CA with a valid CA certificate; properly configured certificate templates, client accounts, and certificate requests; and a way for the client to submit the request to the CA, have the request validated, and install the issued certificate.

Event Details

Product: Windows Operating System
ID: 57
Source: Microsoft-Windows-CertificationAuthority
Version: 6.1
Symbolic Name: MSG_DN_CERT_ADMIN_DENIED_WITH_INFO
Message: Active Directory Certificate Services denied request %1. The request was for %2. Additional information: %3

Resolve
Remove conditions that prevent a certificate request from being approved

Problems in chain building are a common cause for certificate requests to fail. Use the following procedure to validate the certificate chain for the certification authority (CA) and fix any problems that are identified:

  • Confirm user account information in Active Directory Domain Services (AD DS).
  • Confirm certificate template information.
  • Confirm the certificate chain for the CA.
  • Check the most recent certificate revocation lists (CRLs).
  • Publish a new CRL.

If this does not resolve the problem, check and resolve issues in the following areas:

  • The failed requests queue for the CA
  • AD DS connectivity

Signatures that are required to complete the certificate request might not be available. If this is the case:

  • Enable additional users with registration authority certificates to sign certificate requests.
  • Modify the certificate template to require fewer registration authority signatures.
  • Submit the certificate request again.

Confirm user account information in AD DS

To perform this procedure, you must have membership in Domain Admins, or you must have been delegated the appropriate authority.

To confirm user account information:

  1. On the domain controller, click Start, point to Administrative Tools, and click Active Directory Users and Computers.
  2. In the console tree, select the domain and user group in which the user’s account should be located.
  3. If the user account exists, right-click the account, click Properties, and confirm that the user has a properly configured Domain Name System (DNS) name. 

Confirm certificate template information

To perform this procedure, you must have Manage CA permission, or you must have been delegated the appropriate authority.

To confirm certificate template information:

  1. On the computer hosting the CA, click Start, type certtmpl.msc and press ENTER.
  2. Right-click the certificate template that you are troubleshooting, and confirm that the user or group has permissions to enroll for a certificate based on this template.

Confirm the certificate chain for the CA

To validate the chain for the CA:

  1. Click Start, type mmc, and then press ENTER.
  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  3. On the File menu, click Add/Remove Snap-in, click Certificates, and then click Add.
  4. Click Computer account, and click Next.
  5. Select the computer hosting the CA, click Finish, and then click OK.
  6. Select each CA certificate in the certificate chain, and click View Certificate.
  7. Click the Details tab, and click Copy to File to start the Certificate Export Wizard. Save each certificate with a .cer extension.
  8. Open a command prompt and run the following command on each CA certificate: certutil -urlfetch -verify <CAcert.cer> and then press ENTER. Replace <CAcert.cer> with the name of a CA certificate file that you saved in step 7.
  9. Use the same command with a certificate file for an end-entity (user or computer) certificate issued by the CA to confirm CRLs for the CA itself as well as its chain.
  10. Resolve any problems identified in the command line output.

Generate and publish new CRLs

If the command line output indicates that a CRL for a CA has expired, generate new base and delta CRLs on the CA and copy them to the required locations. You may need to restart an offline CA to do this.

On the CA, check the current published CRL. By default, the CA creates CRLs in the folder %windir%\System32\CertSrv\CertEnroll. If the CRLs currently in this location have expired or are invalid, you can use the following procedure to publish a new CRL.

To publish a new CRL by using the Certification Authority snap-in:

  1. On the computer hosting the CA, click Start, point to Administrative Tools, and click Certification Authority.
  2. Select the CA, and expand the folders below the CA name.
  3. Right-click the Revoked Certificates folder.
  4. Click All Tasks, and then click Publish.

You can also generate and publish CRLs from a command prompt.

To publish a CRL by using the Certutil command-line tool:

  1. On the computer hosting the CA, click Start, type cmd and press ENTER..
  2. Type certutil -CRL and press ENTER. 

If a CRL is identified as unavailable but a valid CRL exists in the local directory on the CA, confirm that the CA can connect to the CRL distribution point, and then use the preceding steps to generate and publish CRLs again.

CRLs can be published manually to Active Directory Domain Services (AD DS) by using the following command:

certutil -dspublish”<crlname.crl>” ldap:///CN=<CA name>,CN=<CA hostname>,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=<contoso>,DC=<com>?certificateRevocationList?base?objectClass=cRLDistributionPoint

Replace crlname.crl with the name of your CRL file, <CA name> and <CA hostname> with your CA name and the name of the host on which that CA runs, and <contoso> and <com> with the namespace of your Active Directory domain.

Confirm configured CRL distribution points

Check all configured CRL distribution points to confirm that publication was successful and that new CRLs are available on the network.

To perform this procedure, you must have Manage CA permission, or you must have been delegated the appropriate authority.

To check the configured CRL distribution points by using the Certification Authority snap-in:

  1. On the computer hosting the CA, click Start, point to Administrative Tools, and click Certification Authority.
  2. Right-click the name of the CA, and click Properties.
  3. Click the Extensions tab.
  4. Review the configured CRL distribution points and confirm that the names are valid.

To check the configured CRL distribution point URLs by using Certutil:

  1. Open a command prompt window on the CA. 
  2. Type certutil -getreg ca\crlpublicationurls and press ENTER.
  3. Review the configured CRL distribution points and confirm that the names are valid.

Check the failed requests queue on the CA

To perform this procedure, you must have Manage CA permission, or you must have been delegated the appropriate authority.

To check the failed requests queue on the CA by using the Certification Authority snap-in:

  1. On the computer hosting the CA, click Start, point to Administrative Tools, and click Certification Authority.
  2. Click Failed Requests.
  3. Look for failed requests that were submitted at or near the time of the event, and check columns such as the Request Disposition Message, Request Status Code, and Requester Name for additional diagnostic information.

To check failed requests by using Certutil:

  1. On the computer hosting the CA, click Start, type cmd and press ENTER.
  2. Type certutil -view LogFail and press ENTER.
  3. Type certutil -view -restrict requestID=”<nnn>” and press ENTER. Replace nnn with the Request ID of one of the failed requests in the output of the LogFail command.

Confirm AD DS connectivity

To confirm an Active Directory Certificate Services (AD CS) connection to AD DS:

  1. On the CA, open a command prompt window.
  2. Type ping <server_FQDN>, where server_FQDN is the fully qualified domain name (FQDN) of the domain controller (for example, server1.contoso.com), and then press ENTER.
  3. If the ping was successful, you will receive a reply similar to the following:

    Reply from IP_address: bytes=32 time=3ms TTL=59

    Reply from IP_address: bytes=32 time=20ms TTL=59

    Reply from IP_address: bytes=32 time=3ms TTL=59

    Reply from IP_address: bytes=32 time=6ms TTL=59 3

  4. At the command prompt, type ping <IP_address>, where IP_address is the IP address of the domain controller, and then press ENTER.
  5. If you can successfully connect to the domain controller by IP address but not by FQDN, this indicates a possible issue with Domain Name System (DNS) host name resolution. If you cannot successfully connect to the domain controller by IP address, this indicates a possible issue with network connectivity, firewall configuration, or Internet Protocol security (IPsec) configuration.

Issue additional registration authority certificates

To perform this procedure, you must be a member of local Administrators on the computer hosting the CA, or you must have been delegated the appropriate authority.

To issue additional registration authority certificates:

  1. On the computer hosting the CA, click Start, type certtmpl.msc, and then press ENTER.
  2. In the details pane, right-click the registration authority certificate template, and then click Properties. 
  3. On the Security tab, add the names of the users or groups to whom you want to issue registration authority certificates.
  4. In Group or user names, click one of the new objects, and then, on Permissions forObjectName, under the Allow column, select the Read and Enroll check boxes.
  5. Repeat the previous step for each new object, and click OK.
  6. Click Start, point to Administrative Tools, and click Certification Authority.
  7. Double-click the name of the CA.
  8. Right-click the Certificate Templates container, click New, and then click Certificate Template to Issue.
  9. Select the certificate template, and click OK.

Modify certificate template signature requirements

To perform this procedure, you must have Manage CA permission, or you must have been delegated the appropriate authority.

To modify certificate template signature requirements:

  1. On the computer hosting the CA, click Start, type certtmpl.msc, and then press ENTER.
  2. In the details pane, right-click the certificate template that you want to change, and then click Properties.
  3. Click the Issuance Requirements tab.
  4. Under This number of authorized signatures, enter the number of registration authority signatures you want to use.
  5. Repeat the previous step for each new object, and click OK.
  6. Click Start, point to Administrative Tools, and click Certification Authority.
  7. Double-click the name of the CA.
  8. Right-click the Certificate Templates container, click New, and then click Certificate Template to Issue.
  9. Select the certificate template, and click OK.

Verify

To perform this procedure, you must have permission to request a certificate.

To confirm that certificate request processing is working properly:

  1. Click Start, type certmgr.msc, and then press ENTER.
  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  3. In the console tree, double-click Personal, and then click Certificates.
  4. On the Action menu, point to All Tasks, and click Request New Certificate to start the Certificate Enrollment wizard. 
  5. Use the wizard to create and submit a certificate request for any type of certificate that is available.
  6. Under Certificate Installation Results, confirm that the enrollment completes successfully and no errors are reported. You can also click Details to view additional information about the certificate.

Related Management Information

AD CS Certificate Request (Enrollment) Processing

Active Directory Certificate Services

Related:

Event ID 57 — Terminal Services Client Access License (TS CAL) Availability

Event ID 57 — Terminal Services Client Access License (TS CAL) Availability

Updated: January 5, 2012

Applies To: Windows Server 2008

When a client—either a user or a device—connects to a terminal server, the terminal server determines if a Terminal Services client access license (TS CAL) is needed. The terminal server then requests a TS CAL from a Terminal Services license server on behalf of the client attempting to connect to the terminal server. If an appropriate TS CAL is available from a license server, the TS CAL is issued to the client, and the client will be able to connect to the terminal server.

TS CALs are installed onto a license server by using the TS Licensing Manager tool.

Note:  A terminal server running Windows Server 2008 can only communicate with a license server running Windows Server 2008.

Event Details

Product: Windows Operating System
ID: 57
Source: Microsoft-Windows-TerminalServices-Licensing
Version: 6.0
Symbolic Name: TLS_E_CERTIFICATE_VERIFICATION_FAILED
Message: The certificate chain verification failed with Win32 error code %1!s!. Use the Telephone method to install the Terminal Services client access licenses (TS CALs).

Resolve
Install TS CALs onto the license server by using the telephone method

To resolve this issue, install the Terminal Services client access licenses (TS CALs) onto the Terminal Services license server by using the telephone method. When you call the Microsoft Clearinghouse, ensure that your License Purchase Agreement information is readily available.

To perform this procedure, you must have membership in the local Administrators group, or you must have been delegated the appropriate authority.

To install TS CALs by using the telephone method:

  1. On the license server, open TS Licensing Manager. To open TS Licensing Manager, click Start, point to Administrative Tools, point to Terminal Services, and then click TS Licensing Manager.
  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  3. In the left pane, click All Servers, click the name of the license server, and then on the View menu, click Properties.
  4. On the Connection Method tab, in the Connection method list, select Telephone.
  5. In the Select Country or Region list, select the appropriate country/region.
  6. Click OK to close the Properties dialog box.
  7. Right-click the license server and then click Install Licenses.
  8. Click Next.
  9. On the Obtain client license key pack page, use the telephone number that is displayed to call the Microsoft Clearinghouse, and give the representative your Terminal Services license server ID and the required information for the licensing program through which you purchased your TS CALs. The representative then processes your request to install TS CALs, and gives you a unique ID for the TS CALs. This unique ID is referred to as the license key pack ID.

    Important:  Retain a copy of the license key pack ID. Having this information with you will facilitate communications with the Microsoft Clearinghouse should you need assistance with recovering TS CALs.

  10. In the Install Licenses Wizard, on the Obtain client license key pack page, enter the license key pack ID provided by the representative into the boxes provided, and then click Next. The TS CALs are installed onto the license server.
  11. To complete the process, click Finish. The license server can now issue TS CALs to clients that connect to a terminal server.

Verify

To verify that Terminal Services client access licenses (TS CALs) are installed and available on the Terminal Services license server, use the TS Licensing Manager tool.

To perform this procedure, you must have membership in the local Administrators group, or you must have been delegated the appropriate authority.

To verify that TS CALs are installed and available:

  1. On the license server, open TS Licensing Manager. To open TS Licensing Manager, click Start, point to Administrative Tools, point to Terminal Services, and then click TS Licensing Manager.
  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  3. In the left pane, expand All Servers, and then click the license server. In the right pane, the type, version, and number of TS CALs installed on the license server is listed.

Note:  To verify that the terminal server can discover (contact) a Terminal Services license server with the appropriate type of Terminal Services client access licenses (TS CALs), use Licensing Diagnosis in the Terminal Services Configuration tool on the terminal server.

Related Management Information

Terminal Services Client Access License (TS CAL) Availability

Terminal Services

Related:

Outlook Web Access is not available for this mailbox. If the problem continues, contact technical support for your organization and tell them the following: The Client Access server %1, running Microsoft Exchange version %2, attempted to find a Client Access server to proxy Outlook Web Access traffic for mailbox %3. The service discovery failed in looking up the Client Access server in the target Active Directory site.Additional information: %4.

Details
Product: Exchange
Event ID: 57
Source: MSExchange OWA
Version: 8.0
Symbolic Name: ProxyErrorServiceDiscovery
Message: Outlook Web Access is not available for this mailbox. If the problem continues, contact technical support for your organization and tell them the following: The Client Access server %1, running Microsoft Exchange version %2, attempted to find a Client Access server to proxy Outlook Web Access traffic for mailbox %3. The service discovery failed in looking up the Client Access server in the target Active Directory site.Additional information: %4.
   
Explanation

This Warning event indicates that the computer that is running the Client Access (CAS) server role could not determine the Client Access server that should handle a Microsoft Office Outlook Web Access request. Specifically, it could not determine whether the request should be processed by the local Client Access server, or if it should be proxied or redirected to a Client Access server in a different Active Directory site. Therefore, the mailbox specified in the event description could not be accessed through Outlook Web Access. This event may be caused by one or more of the following:

  • The Client Access server cannot verify the location of servers that are running Microsoft Exchange Server in Active Directory sites.

  • The Client Access server cannot verify the links between the Active Directory sites.

  • The Client Access server cannot access required Exchange Server virtual directory configuration data from Active Directory.

  • The Client Access server that accepts Outlook Web Access proxy or redirection requests is not in the same Active Directory site as the computer that is running the Mailbox server role.

For more information about Outlook Web Access proxying and redirection, see Understanding Proxying and Redirection.

   
User Action

To resolve this error, take one or more of these steps:

  • If this occurs frequently, check network connectivity between the Client Access Server and domain controllers. Use the Ping or PathPing command-line tools to test basic connectivity. Use Ping to isolate network hardware problems and incompatible configurations. Use PathPing to detect packet loss over multiple-hop trips. For more information, see Microsoft Knowledge Base article 325487, How to troubleshoot network connectivity problems.

  • Make sure that the InternalUrl of the Outlook Web Access virtual directory exists and that it matches the fully qualified domain name (FQDN) of the local CAS server.

If you are not already doing so, consider running the tools that Microsoft Exchange offers to help administrators analyze and troubleshoot their Exchange environment. These tools can help you make sure that your configuration is in line with Microsoft best practices. They can also help you identify and resolve performance issues, improve mail flow, and better manage disaster recovery scenarios. Go to the Toolbox node of the Exchange Management Console to run these tools now. For more information about these tools, see Toolbox in the Exchange Server 2007 Help.

Related:

The system failed to flush data to the transaction log. Corruption may occur.

Details
Product: Windows Operating System
Event ID: 57
Source: ftdisk
Version: 5.2
Symbolic Name: IO_WARNING_LOG_FLUSH_FAILED
Message: The system failed to flush data to the transaction log. Corruption may occur.
   
Explanation

NTFS could not write data to the transaction log. This could affect the ability of NTFS to stop or roll back the operations for which the transaction data could not be written. NTFS could not write data because of one or more of the following reasons:

  1. I/O requests issued by the file system to the disk subsystem might not have been completed successfully.
   
User Action

If this message appears frequently, run Chkdsk to repair the file system.

To repair the file system

  1. Save any unsaved data and close any open programs.
  2. Restart the computer.
    The volume is automatically checked and repaired when you restart the computer.

Alternatively, you can run the Chckdsk tool from the command prompt without shutting down the computer first.

  1. Click Start, click Run, and then type
    cmd
  2. At the command prompt, type
    chkdsk /R /X Drive:
    Chkdsk runs and automatically repairs the volume.
  3. Repeat step 2 for each volume on the disk.

If the following message appears, type Y.

“Cannot lock current drive. Chkdsk cannot run because the volume is in use by another process. Would you like to schedule this volume to be checked the next time the system restarts?”

The next time the computer is started, Chkdsk will automatically run.

Related: