Partager via


3.1.4.26 NetrServerTransportDelEx (Opnum 53)

The server receives the NetrServerTransportDelEx method in an RPC_REQUEST packet. In response, the server unbinds (or disconnects) the transport protocol from the server. If this method succeeds, the server can no longer communicate with clients by using the specified transport protocol (such as TCP or XNS). This extended method allows level 1 beyond what the NetrServerTransportDel method allows.

 NET_API_STATUS NetrServerTransportDelEx(
   [in, string, unique] SRVSVC_HANDLE ServerName,
   [in] DWORD Level,
   [in, switch_is(Level)] LPTRANSPORT_INFO Buffer
 );

ServerName: An SRVSVC_HANDLE (section 2.2.1.1) pointer that identifies the server. The client MUST map this structure to an RPC binding handle (see [C706] sections 4.3.5 and 5.1.5.2). The server MUST ignore this parameter.

Level: Specifies the information level of the data. It MUST be one of the following values.

Value

Meaning

0

The buffer is of type SERVER_XPORT_INFO_0_CONTAINER.

1

The buffer is of type SERVER_XPORT_INFO_1_CONTAINER.

Buffer: A pointer to the TRANSPORT_INFO union that contains information about the transport. The value of the Level parameter determines the type of the contents of the Buffer parameter, as the preceding table shows.

Return Values: The method returns 0x00000000 (NERR_Success) to indicate success; otherwise, it returns a nonzero error code. The method can take any specific error code value, as specified in [MS-ERREF] section 2.2.<100>

The Level parameter determines the type of structure the client has used to specify information about the new transport. Valid values are 0 and 1. If the Level parameter is not equal to one of the valid values, the server MUST fail the call with an ERROR_INVALID_LEVEL error code.

If the Level parameter is 0, the Buffer parameter points to a SERVER_TRANSPORT_INFO_0 structure. If the Level parameter is 1, the Buffer parameter points to a SERVER_TRANSPORT_INFO_1 structure.

The server MUST validate all information that is provided in the SERVER_TRANSPORT_INFO structure in an implementation-specific manner, and, if any member of the structure is found to be invalid, the server MUST fail the call with an ERROR_INVALID_PARAMETER error code.

The server MUST look up the Transport in the TransportList, where Transport.Name matches the caller-supplied svti*_transportname and Transport.ServerName matches the caller-supplied svti*_ transportaddress. If a match is not found, the server MUST return NERR_NetNameNotFound  to the caller.

If a match is found, the server MUST invoke the events described in [MS-CIFS] section 3.3.4.17 and [MS-SMB2] section 3.3.4.21, passing Transport.ServerName, Transport.Name, and a transport enable flag set to FALSE as the parameters. This means that the SMB file server can no longer initiate communications with clients by using the specified transport protocol (such as SMB2 over Direct TCP).<101>

If both the CIFS and SMB2 servers return ERROR_NOT_SUPPORTED, the server MUST return ERROR_NOT_SUPPORTED (0x00000032) to the caller. If both the CIFS and SMB2 servers return an error other than ERROR_NOT_SUPPORTED, the server must fail the call with an implementation-dependent error.

If either the CIFS or SMB2 server returns STATUS_SUCCESS, the server MUST remove Transport from TransportList and from the persistent store, free the transport object and return NERR_Success.

The server SHOULD<102> enforce security measures to verify that the caller has the required permissions to execute this call. If the caller does not have the required credentials, the server SHOULD<103> fail the call.