Event ID 8247 — UNIX to Windows Password Synchronization Service — Run-time Issues

Event ID 8247 — UNIX to Windows Password Synchronization Service — Run-time Issues

Updated: December 16, 2008

Applies To: Windows Server 2008 R2

UNIX to Windows Password Synchronization Service — Run-time Issues indicates the functionality of UNIX to Windows password synchronization operations.

When Password Synchronization is configured for UNIX to Windows synchronization, and UNIX to Windows synchronization is functioning normally, passwords that are changed on UNIX hosts are synchronized on Windows-based computers and domains. The Password Synchronization pluggable authentication module (PAM) makes this possible by intercepting the password change request on the UNIX host, encrypting the password, and then sending the password change request to the Password Synchronization service running on the Windows-based computers with which it is configured to be synchronized.

Event Details

Product: Windows Identity Management for UNIX
ID: 8247
Source: Microsoft-Windows-IDMU-PSync
Version: 6.0
Symbolic Name: MSG_ERROR_ACQUIRE_CRYPTCONTEXT_FAILED
Message: Error occurred in acquiring handle to Cryptographic Service Provider. Error=%1

Resolve
Fix possible failures for Win32 API

Password Synchronization is unable to update a user password because it experienced a failure attempting to call a Windows API.

Read the full text of the error message in Event Viewer to obtain the exact Windows error code.

To correct the error, try the following steps in order, moving on to the next step only if the current action failed to clear the error condition:

  1. Free virtual memory by closing unused applications.
  2. Restart the Password Synchronization service.
  3. Restart the computer on which the error was generated.

Verify

To verify the functional state of UNIX to Windows password synchronization, retry UNIX to Windows password synchronization. UNIX to Windows password synchronization is fully operational when the password synchronization succeeds, and functioning with warning conditions present if password synchronization fails for some passwords but succeeds for others.

If password synchronization succeeds for some passwords but fails for others, the UNIX to Windows Password Synchronization Service is likely fully operational, but there might be account- or computer-specific configuration problems preventing password changes from being synchronized on UNIX-based hosts.

Related Management Information

UNIX to Windows Password Synchronization Service — Run-time Issues

Identity Management for UNIX

Related:

Event ID 8245 — Windows to UNIX Password Synchronization Service — Run-time Issues

Event ID 8245 — Windows to UNIX Password Synchronization Service — Run-time Issues

Updated: November 14, 2007

Applies To: Windows Server 2008

Windows to UNIX Password Synchronization Service — Run-time Issues indicates the functionality of Windows to UNIX password synchronization operations.

When Password Synchronization is configured for Windows-to-UNIX synchronization, and a password is changed on a Windows-based computer running Password Synchronization, the Password Synchronization service determines whether the user’s password is to be synchronized on UNIX computers. When the Password Synchronization service is operating normally, it encrypts the password and sends it to the Password Synchronization daemon on each computer with which the Windows-based computer is configured to be synchronized. The daemon then decrypts the password and changes the password on the UNIX host.

Event Details

Product: Windows Identity Management for UNIX
ID: 8245
Source: Microsoft-Windows-IDMU-PSync
Version: 6.0
Symbolic Name: MSG_PSWD_CHANGE_PROP_NOT_DONE
Message: Password propagation failed. Either default encryption key is configured or no UNIX hosts are configured to propagate passwords.

Resolve
Check best practices for Password Synchronization

This error typically originates in the UNIX environment. Make certain that Password Synchronization has been configured in accordance with guidelines in Best practices for Password Synchronization, an excerpt of which follows in this topic. In particular, password policies in both the Windows and UNIX environments should have similar restrictions, and minimum requirements for character length and complexity of passwords should be as closely matched as possible.

Best Practices for Password Synchronization

  • Ensure consistent password policies If you are providing only for one-way password synchronization, make sure that the password policy on the computer from which passwords will be synchronized is at least as restrictive in all areas as the policy on the computer to which passwords will by synchronized. For example, if you configure Windows-to-UNIX synchronization, the Windows password policy must be at least as restrictive as the policy of the UNIX computers with which it will synchronize passwords. If you are supporting two-way synchronization, the password policies must be equally restrictive on both systems. Failure to ensure that password policies are consistent can result in synchronization failure when a user changes a password on the less restrictive system, or the password might be changed on the more restrictive system even though it does not conform to the system’s policies. Also make sure that Windows users are aware of any special password restrictions on the UNIX systems with which their passwords will be synchronized. For example, some versions of UNIX support a maximum password length of eight characters. For maximum compatibility with the default Windows password policy and these UNIX limitations, passwords should be seven or eight characters long unless you are sure that all UNIX systems can support longer passwords.

Verify

Retry Windows to UNIX password synchronization for failed user password changes to verify that it is operational. Password Synchronization is fully operational when the password synchronization succeeds, and operating under warning conditions if password synchronization fails for some passwords but succeeds for others.

If password synchronization succeeds for some passwords but fails for others, the Windows to UNIX Password Synchronization Service is likely fully operational, but there might be account- or computer-specific configuration problems preventing password changes from being synchronized on UNIX-based hosts.

Related Management Information

Windows to UNIX Password Synchronization Service — Run-time Issues

Identity Management for UNIX

Related:

Event ID 8244 — UNIX to Windows Password Synchronization Service Availability

Event ID 8244 — UNIX to Windows Password Synchronization Service Availability

Updated: November 14, 2007

Applies To: Windows Server 2008

UNIX to Windows Password Synchronization Service Availability provides information to help you interpret system messages indicating the operational state of the UNIX to Windows password synchronization service and its availability to synchronize user account passwords to the Windows environment that are changed in the UNIX environment.

When Password Synchronization is configured for UNIX to Windows synchronization, and the synchronization service is available, passwords that are changed on UNIX hosts are synchronized on Windows-based computers and domains. The Password Synchronization pluggable authentication module (PAM) makes this possible by intercepting the password change request on the UNIX host, encrypting the password, and then sending the password change request to the Password Synchronization service running on the Windows-based computers with which it is configured to be synchronized.

The UNIX to Windows Password Synchronization Service is generally available unless the Password Synchronization daemon has failed to initialize.

Event Details

Product: Windows Identity Management for UNIX
ID: 8244
Source: Microsoft-Windows-IDMU-PSync
Version: 6.0
Symbolic Name: MSG_ERROR_SET_SOCKET_OPT_CONDITIONAL_ACCEPT_FAILD
Message: Failed to set socket option. %rerror = %1

Resolve
Correct Windows Sockets error

This is typically the result of a Windows Sockets call failure. Open the message in Event Viewer to determine the exact nature of the error. The error message text should identify the API to which a call failed. Refer to MSDN documentation (http://go.microsoft.com/fwlink/?LinkId=95108) for possible causes of the error with the referenced API, and for ways to correct the problem.

Verify

The UNIX to Windows password synchronization service state is considered fully operational in the absence of any of the following messages in Event Viewer. If any of the following messages are logged in Event Viewer, critical error conditions exist that are preventing the UNIX to Windows password synchronization service from operating normally.

  • IDMU Password Synchronization event 8211
  • IDMU Password Synchronization event 12295
  • IDMU Password Synchronization event 8244
  • IDMU Password Synchronization event 8213

Related Management Information

UNIX to Windows Password Synchronization Service Availability

Identity Management for UNIX

Related:

Event ID 8243 — Windows to UNIX Password Synchronization Service — Run-time Issues

Event ID 8243 — Windows to UNIX Password Synchronization Service — Run-time Issues

Updated: November 14, 2007

Applies To: Windows Server 2008

Windows to UNIX Password Synchronization Service — Run-time Issues indicates the functionality of Windows to UNIX password synchronization operations.

When Password Synchronization is configured for Windows-to-UNIX synchronization, and a password is changed on a Windows-based computer running Password Synchronization, the Password Synchronization service determines whether the user’s password is to be synchronized on UNIX computers. When the Password Synchronization service is operating normally, it encrypts the password and sends it to the Password Synchronization daemon on each computer with which the Windows-based computer is configured to be synchronized. The daemon then decrypts the password and changes the password on the UNIX host.

Event Details

Product: Windows Identity Management for UNIX
ID: 8243
Source: Microsoft-Windows-IDMU-PSync
Version: 6.0
Symbolic Name: MSG_ERROR_PASSWORD_LENGTH_LESS
Message: Password on UNIX side requires more characters. %ruser = %1 %rhost = %2

Resolve
Check best practices for Password Synchronization

This error typically originates in the UNIX environment. Make certain that Password Synchronization has been configured in accordance with guidelines in Best practices for Password Synchronization, an excerpt of which follows in this topic. In particular, password policies in both the Windows and UNIX environments should have similar restrictions, and minimum requirements for character length and complexity of passwords should be as closely matched as possible.

Best Practices for Password Synchronization

  • Ensure consistent password policies If you are providing only for one-way password synchronization, make sure that the password policy on the computer from which passwords will be synchronized is at least as restrictive in all areas as the policy on the computer to which passwords will by synchronized. For example, if you configure Windows-to-UNIX synchronization, the Windows password policy must be at least as restrictive as the policy of the UNIX computers with which it will synchronize passwords. If you are supporting two-way synchronization, the password policies must be equally restrictive on both systems. Failure to ensure that password policies are consistent can result in synchronization failure when a user changes a password on the less restrictive system, or the password might be changed on the more restrictive system even though it does not conform to the system’s policies. Also make sure that Windows users are aware of any special password restrictions on the UNIX systems with which their passwords will be synchronized. For example, some versions of UNIX support a maximum password length of eight characters. For maximum compatibility with the default Windows password policy and these UNIX limitations, passwords should be seven or eight characters long unless you are sure that all UNIX systems can support longer passwords.

Verify

Retry Windows to UNIX password synchronization for failed user password changes to verify that it is operational. Password Synchronization is fully operational when the password synchronization succeeds, and operating under warning conditions if password synchronization fails for some passwords but succeeds for others.

If password synchronization succeeds for some passwords but fails for others, the Windows to UNIX Password Synchronization Service is likely fully operational, but there might be account- or computer-specific configuration problems preventing password changes from being synchronized on UNIX-based hosts.

Related Management Information

Windows to UNIX Password Synchronization Service — Run-time Issues

Identity Management for UNIX

Related:

Event ID 8242 — Server for NIS Functionality — Push Service

Event ID 8242 — Server for NIS Functionality — Push Service

Updated: November 14, 2007

Applies To: Windows Server 2008

Server for NIS synchronizes and propagates NIS map changes to UNIX-based NIS subordinate (also known as slave) servers. The NIS master server supports the following transfer modes:

  • Periodic transfer of NIS maps
  • On-demand transfer of NIS maps to subordinate servers

Typically, NIS maps are transferred to subordinate servers upon change by using the make utility. The Windows-based NIS server does not use make; instead, the server pushes immediately.

Subordinate NIS servers can request transfer of maps at any time. Server for NIS Server Functionality — Push Service provides information to help you interpret system messages indicating the functional state of the NIS map push service.

Event Details

Product: Windows Identity Management for UNIX
ID: 8242
Source: Microsoft-Windows-IDMU-ServerForNIS
Version: 6.0
Symbolic Name: MSG_ERROR_REG_NOTIFY_KEY_CHANGE
Message: An error occurred during notification of a registry key change: %1.

Resolve
Fix possible failures for Win32 API

The Server for NIS push service experienced a failure attempting to call a Windows API.

Read the full text of the error message in Event Viewer to obtain the exact Windows error code. Try the following, in the order shown, to correct the error, moving on to the next step only if the current action failed to clear the error condition:

  1. Free virtual memory by closing unused applications.
  2. Restart the Server for NIS service.
  3. Restart the computer on which the error was generated.

Verify

Server for NIS push service functionality can be verified by pushing maps to subordinate servers.

To test the functionality of the push service, change a map entry for an NIS user (you can use the users nisadmin or AdminUI for the purposes of your test). Wait for the refresh interval to elapse, and then view the NIS map stored on a UNIX-based subordinate of the master server. If your changed values are reflected in the NIS map stored on the UNIX-based NIS subordinate server, then the Server for NIS master server is functioning as expected.

In the absence of any of the following error messages, the push service is functioning normally. If any of these messages occur, the push service can continue working, but warning conditions exist.

  • IDMU Server for NIS event 8198
  • IDMU Server for NIS event 12288
  • IDMU Server for NIS event 12289

Related Management Information

Server for NIS Functionality — Push Service

Identity Management for UNIX

Related:

Event ID 8241 — Server for NIS Functionality — Push Service

Event ID 8241 — Server for NIS Functionality — Push Service

Updated: November 14, 2007

Applies To: Windows Server 2008

Server for NIS synchronizes and propagates NIS map changes to UNIX-based NIS subordinate (also known as slave) servers. The NIS master server supports the following transfer modes:

  • Periodic transfer of NIS maps
  • On-demand transfer of NIS maps to subordinate servers

Typically, NIS maps are transferred to subordinate servers upon change by using the make utility. The Windows-based NIS server does not use make; instead, the server pushes immediately.

Subordinate NIS servers can request transfer of maps at any time. Server for NIS Server Functionality — Push Service provides information to help you interpret system messages indicating the functional state of the NIS map push service.

Event Details

Product: Windows Identity Management for UNIX
ID: 8241
Source: Microsoft-Windows-IDMU-ServerForNIS
Version: 6.0
Symbolic Name: MSG_ERROR_CREATE_EVENT
Message: Failed to create an event: %1.

Resolve
Fix possible failures for Win32 API

The Server for NIS push service experienced a failure attempting to call a Windows API.

Read the full text of the error message in Event Viewer to obtain the exact Windows error code. Try the following, in the order shown, to correct the error, moving on to the next step only if the current action failed to clear the error condition:

  1. Free virtual memory by closing unused applications.
  2. Restart the Server for NIS service.
  3. Restart the computer on which the error was generated.

Verify

Server for NIS push service functionality can be verified by pushing maps to subordinate servers.

To test the functionality of the push service, change a map entry for an NIS user (you can use the users nisadmin or AdminUI for the purposes of your test). Wait for the refresh interval to elapse, and then view the NIS map stored on a UNIX-based subordinate of the master server. If your changed values are reflected in the NIS map stored on the UNIX-based NIS subordinate server, then the Server for NIS master server is functioning as expected.

In the absence of any of the following error messages, the push service is functioning normally. If any of these messages occur, the push service can continue working, but warning conditions exist.

  • IDMU Server for NIS event 8198
  • IDMU Server for NIS event 12288
  • IDMU Server for NIS event 12289

Related Management Information

Server for NIS Functionality — Push Service

Identity Management for UNIX

Related:

Event ID 8240 — Server for NIS Service Availability

Event ID 8240 — Server for NIS Service Availability

Updated: November 14, 2007

Applies To: Windows Server 2008

Server for NIS service availability indicates the functional state of the Server for NIS service. When Server for NIS is available, it updates NIS maps on all subordinate servers in the domain if it is running as an NIS master server, and accepts NIS replication data from Active Directory if it is running as a subordinate server.

Event Details

Product: Windows Identity Management for UNIX
ID: 8240
Source: Microsoft-Windows-IDMU-ServerForNIS
Version: 6.0
Symbolic Name: MSG_ERROR_GET_COMPUTER_NAME
Message: Failure getting computer name: %1.

Resolve
Fix possible failures for Win32 API

Server for NIS is closing because it experienced a failure attempting to call a Windows API. Read the full text of the error message in Event Viewer to obtain the exact Windows error code.

To correct the error, try the following steps in order, moving on to the next step only if the current action failed to clear the error condition:

  1. Free virtual memory by closing unused applications.
  2. Restart the Server for NIS service.
  3. Restart the computer on which the error was generated.

Verify

Open the Services MMC and verify that Server for NIS is operational. If the Server for NIS service properties show that the service is not running, errors are preventing Server for NIS from operating normally.

To verify that Server for NIS is running

  1. Click Start, point to Administrative Tools, and then click Services.
  2. In the Results pane of the Services MMC, double-click Server for NIS.
  3. In the Service status area of the Server for NIS Properties dialog box, verify that the Server for NIS service shows as Started.

Use the ypcat command on a client computer in the domain on which the error was generated to verify that the Server for NIS service is available.

To use the ypcat command to verify Server for NIS service availability:

  1. On a client computer in the domain on which the error was generated, open a Windows Command Prompt with elevated privileges. To do this, right click Command Prompt on the Start menu, and then click Run as administrator.
  2. Type the following command, and then press Enter: ypcat -hNISServer-dDomain Mapname. NISServer represents the name of the server on which you want to verify that the Server for NIS Service is available. Domain represents the domain name on which you want to verify that the Server for NIS service is available. Mapname represents the name or nickname of a specific NIS map that the server on which you want to verify Server for NIS availability is expected to update.
  3. If you are prompted to provide the domain administrator account name and password, type the account name and password, and then press Enter.
  4. The ypcat Windows command-line utility prints the values of all keys from the NIS database specified by Mapname, which can be a map name or a map nickname. If the ypcat utility returns a list of key values for the maps you specified, the Server for NIS service is available.

Related Management Information

Server for NIS Service Availability

Identity Management for UNIX

Related:

Event ID 8232 — UNIX to Windows Password Synchronization Service — Run-time Issues

Event ID 8232 — UNIX to Windows Password Synchronization Service — Run-time Issues

Updated: December 16, 2008

Applies To: Windows Server 2008 R2

UNIX to Windows Password Synchronization Service — Run-time Issues indicates the functionality of UNIX to Windows password synchronization operations.

When Password Synchronization is configured for UNIX to Windows synchronization, and UNIX to Windows synchronization is functioning normally, passwords that are changed on UNIX hosts are synchronized on Windows-based computers and domains. The Password Synchronization pluggable authentication module (PAM) makes this possible by intercepting the password change request on the UNIX host, encrypting the password, and then sending the password change request to the Password Synchronization service running on the Windows-based computers with which it is configured to be synchronized.

Event Details

Product: Windows Identity Management for UNIX
ID: 8232
Source: Microsoft-Windows-IDMU-PSync
Version: 6.0
Symbolic Name: MSG_PASSWORD_CANT_CHANGE
Message: User can’t change password. %ruser = %1

Resolve
Make sure the password can be changed

The user cannot change the password. Users can be prevented from changing their own passwords by Group Policy settings, such as the domain-level policy setting Refuse machine account password changes.

The user can also have difficulty changing passwords if password policies are not equally restrictive in both the Windows and UNIX environments. Ensure that password policies on Windows and UNIX computers that synchronize passwords are similar. Otherwise, if the user changes the password on the less restrictive computer, the more restrictive system might not accept the new password. Password policies that control minimum and maximum length, character case and alphanumeric mix, expiration, and reuse must be as close as possible between Windows and UNIX computers that synchronize passwords. Also, Windows and UNIX system administrators must ensure that user names, including case, are identical on the Windows and UNIX computers. For more information, see Best practices for Password Synchronization.

Best Practices for Password Synchronization

  • Ensure consistent password policies If you are providing only for one-way password synchronization, make sure that the password policy on the computer from which passwords will be synchronized is at least as restrictive in all areas as the policy on the computer to which passwords will by synchronized. For example, if you configure Windows-to-UNIX synchronization, the Windows password policy must be at least as restrictive as the policy of the UNIX computers with which it will synchronize passwords. If you are supporting two-way synchronization, the password policies must be equally restrictive on both systems. Failure to ensure that password policies are consistent can result in synchronization failure when a user changes a password on the less restrictive system, or the password might be changed on the more restrictive system even though it does not conform to the system’s policies.

    Also make sure that Windows users are aware of any special password restrictions on the UNIX systems with which their passwords will be synchronized. For example, some versions of UNIX support a maximum password length of eight characters. For maximum compatibility with the default Windows password policy and these UNIX limitations, passwords should be seven or eight characters long unless you are sure that all UNIX systems can support longer passwords.

Verify

To verify the functional state of UNIX to Windows password synchronization, retry UNIX to Windows password synchronization. UNIX to Windows password synchronization is fully operational when the password synchronization succeeds, and functioning with warning conditions present if password synchronization fails for some passwords but succeeds for others.

If password synchronization succeeds for some passwords but fails for others, the UNIX to Windows Password Synchronization Service is likely fully operational, but there might be account- or computer-specific configuration problems preventing password changes from being synchronized on UNIX-based hosts.

Related Management Information

UNIX to Windows Password Synchronization Service — Run-time Issues

Identity Management for UNIX

Related:

Event ID 8231 — UNIX to Windows Password Synchronization Service — Run-time Issues

Event ID 8231 — UNIX to Windows Password Synchronization Service — Run-time Issues

Updated: December 16, 2008

Applies To: Windows Server 2008 R2

UNIX to Windows Password Synchronization Service — Run-time Issues indicates the functionality of UNIX to Windows password synchronization operations.

When Password Synchronization is configured for UNIX to Windows synchronization, and UNIX to Windows synchronization is functioning normally, passwords that are changed on UNIX hosts are synchronized on Windows-based computers and domains. The Password Synchronization pluggable authentication module (PAM) makes this possible by intercepting the password change request on the UNIX host, encrypting the password, and then sending the password change request to the Password Synchronization service running on the Windows-based computers with which it is configured to be synchronized.

Event Details

Product: Windows Identity Management for UNIX
ID: 8231
Source: Microsoft-Windows-IDMU-PSync
Version: 6.0
Symbolic Name: MSG_PASSWORD_EXPIRED
Message: Error changing password. Password expired for user. %ruser = %1

Resolve
Make sure that the password has not expired

An error occurred while attempting to change the user’s password because the original password has expired. Typically, Windows users with expired passwords contact the domain administrators for their domains, request temporary passwords that will allow them to log on to the network, and then change their passwords. Users of UNIX-based operating systems should contact their UNIX system administrators for temporary passwords or network access.

Verify

To verify the functional state of UNIX to Windows password synchronization, retry UNIX to Windows password synchronization. UNIX to Windows password synchronization is fully operational when the password synchronization succeeds, and functioning with warning conditions present if password synchronization fails for some passwords but succeeds for others.

If password synchronization succeeds for some passwords but fails for others, the UNIX to Windows Password Synchronization Service is likely fully operational, but there might be account- or computer-specific configuration problems preventing password changes from being synchronized on UNIX-based hosts.

Related Management Information

UNIX to Windows Password Synchronization Service — Run-time Issues

Identity Management for UNIX

Related:

Event ID 8229 — Server for NIS Service Availability

Event ID 8229 — Server for NIS Service Availability

Updated: November 14, 2007

Applies To: Windows Server 2008

Server for NIS service availability indicates the functional state of the Server for NIS service. When Server for NIS is available, it updates NIS maps on all subordinate servers in the domain if it is running as an NIS master server, and accepts NIS replication data from Active Directory if it is running as a subordinate server.

Event Details

Product: Windows Identity Management for UNIX
ID: 8229
Source: Microsoft-Windows-IDMU-ServerForNIS
Version: 6.0
Symbolic Name: MSG_PUSHTHREAD_FAILURE
Message: PushThread creation failed.

Resolve
Close some applications and restart Server for NIS

A server thread creation failure occurred. This can occur if the Windows operating system is running low on virtual memory, or if the server’s performance or health is significantly degraded. Close unused applications, or close all applications and restart Server for NIS. If that fails to correct the problem, close all applications and restart the server.

Restart Server for NIS by using the Windows interface

To restart Server for NIS by using the Windows interface:

  1. Open the Identity Management for UNIX management console.
  2. If necessary, connect to the computer you want to manage.
  3. Right-click Server for NIS, and then click Stop.
  4. Right-click Server for NIS again, and then click Start.

Restart Server for NIS by using a command line

To restart Server for NIS by using a command line:

  1. Open a Command Prompt window.
  2. Type the following, and then press ENTER.
    • nisadmin [server] stop [–u user [–p password]]
  3. Type the following, and then press ENTER.
    • nisadmin [server] start [–u user [–p password]]

For more information, see the topic “Start or stop Identity Management for UNIX components” in the Identity Management for UNIX Help.

To restart the computer:

  • Click Start, click the arrow next to the Lock button, and then click Restart.

Verify

Open the Services MMC and verify that Server for NIS is operational. If the Server for NIS service properties show that the service is not running, errors are preventing Server for NIS from operating normally.

To verify that Server for NIS is running

  1. Click Start, point to Administrative Tools, and then click Services.
  2. In the Results pane of the Services MMC, double-click Server for NIS.
  3. In the Service status area of the Server for NIS Properties dialog box, verify that the Server for NIS service shows as Started.

Use the ypcat command on a client computer in the domain on which the error was generated to verify that the Server for NIS service is available.

To use the ypcat command to verify Server for NIS service availability:

  1. On a client computer in the domain on which the error was generated, open a Windows Command Prompt with elevated privileges. To do this, right click Command Prompt on the Start menu, and then click Run as administrator.
  2. Type the following command, and then press Enter: ypcat -hNISServer-dDomain Mapname. NISServer represents the name of the server on which you want to verify that the Server for NIS Service is available. Domain represents the domain name on which you want to verify that the Server for NIS service is available. Mapname represents the name or nickname of a specific NIS map that the server on which you want to verify Server for NIS availability is expected to update.
  3. If you are prompted to provide the domain administrator account name and password, type the account name and password, and then press Enter.
  4. The ypcat Windows command-line utility prints the values of all keys from the NIS database specified by Mapname, which can be a map name or a map nickname. If the ypcat utility returns a list of key values for the maps you specified, the Server for NIS service is available.

Related Management Information

Server for NIS Service Availability

Identity Management for UNIX

Related: