Repair Windows

In computer networking, Server Message Block (SMB) operates as an application-layer network protocol mainly used to provide shared access to files, printers, serial ports, and miscellaneous communications between nodes on a network. It also provides an authenticated Inter-process communication mechanism. Most usage of SMB involves computers running Microsoft Windows, where it is often known as "Microsoft Windows Network".
When discussing SMB, one should distinguish:

• the SMB protocol specification
• the "server" and "workstation" services that implement the protocol on Windows
• the Samba service that implements the protocol on Unix systems
• NetBIOS transport used by SMB on legacy versions of Windows
• the DCE/RPC services that use SMB as an authenticated Inter-process communication channel (over named pipes)
• the "Network Neighborhood" protocols which primarily (but not exclusively) run as datagram services directly on the NetBIOS transport

History Barry Feigenbaum originally designed SMB at IBM with the aim of turning DOS "Interrupt 33" (21h) local file-access into a networked file-system. Microsoft has made considerable modifications to the version used most commonly. Microsoft merged the SMB protocol with the LAN Manager product which it had started developing for OS/2 with 3Com circa 1990, and continued to add features to the protocol in Windows for Workgroups (circa 1992) and in later versions of Windows.The original design of SMB envisaged it running on top of the NetBIOS/NetBEUI API (typically implemented with NBF, NetBIOS over IPX/SPX, or NBT). Since Windows 2000, SMB runs by default directly on top of TCP — a feature known as "direct host SMB" where the server service listens on TCP port 445.
At around the time when Sun Microsystems announced WebNFS, Microsoft launched an initiative in 1996 to rename SMB to Common Internet File System (CIFS) (pronounced /ˈkɪfs/), and added more features, including support for symbolic links, hard links, larger file sizes, and an initial attempt at supporting direct connections over TCP port 445 without all the NetBIOS trimmings (a largely experimental effort that required further refinement). Microsoft submitted some partial specifications as Internet-Drafts to the IETF, though these submissions have expired.
Because of the importance of the SMB protocol in interacting with the widespread Microsoft Windows platform, coupled with the heavily modified nature of the SMB implementation present in that platform, the Samba project originated with the aim of reverse engineering and providing a free implementation of a compatible SMB client and server for use with non-Microsoft operating systems.
Microsoft introduced SMB2 with Windows Vista in 2006.

Implementation 

Client-server approach SMB works through a client-server approach, where a client makes specific requests and the server responds accordingly. One section of the SMB protocol specifically deals with access to filesystems, such that clients may make requests to a file server; but some other sections of the SMB protocol specialize in inter-process communication (IPC). Developers have optimized the SMB protocol for local subnet usage, but users have also put SMB to work to access different subnets across the Internet — exploits involving file-sharing or print-sharing in MS Windows environments usually focus on such usage.
SMB (Server Message Block) servers make their file systems and other resources available to clients on the network. Client computers may want access to the shared file systems and printers on the server, and in this primary functionality SMB has become best-known and most heavily used. However, the SMB file-server aspect would count for little without the NT domains suite of protocols, which provide NT-style domain-based authentication at the very least. Almost all implementations of SMB servers use NT Domain authentication to validate user-access to resources. 

Performance issues NetBIOS The use of the SMB protocol has often correlated with a significant increase in broadcast traffic on a network. However the SMB itself does not use broadcasts—the broadcast problems commonly associated with SMB actually originate with the NetBIOS service location protocol. By default, a Microsoft Windows NT 4.0 server used NetBIOS to advertise and locate services. NetBIOS functions by broadcasting services available on a particular host at regular intervals. While this usually makes for an acceptable default in a network with a smaller number hosts, increased broadcast traffic can cause problems on an unswitched network as the number of hosts increases. The implementation of name resolution infrastructure in the form of Windows Internet Naming Service (WINS) or Domain Name System (DNS) resolves this problem. WINS was a proprietary implementation used with Windows NT 4.0 networks, but brought about its own issues and complexities in the design and maintenance of a Microsoft network.
Since the release of Windows 2000, the use of WINS for name resolution has been deprecated by Microsoft, with Dynamic DNS now configured as the default name resolution protocol for all Windows operating systems. WINS can still be configured as a secondary name resolution protocol for interoperability with legacy Windows environments. Further, Microsoft DNS servers can forward name resolution requests to legacy WINS servers in order to support name resolution integration with legacy (pre-Windows 2000) environments that do not support DNS.

WAN performance Network designers have found that latency has a significant impact on the performance of the SMB 1.0 protocol, that it performs more poorly than other protocols like FTP. Monitoring reveals a high degree of "chattiness" and a disregard of network latency between hosts. For example, a VPN connection over the Internet will often introduce network latency. Microsoft has explained that performance issues come about primarily because SMB 1.0 is a block-level rather than a streaming protocol, that was originally designed for small LANs; it has a block size that is limited to 64K, SMB signing creates an additional overhead and the TCP window size is not optimized for WAN links. Solutions to this problem include the updated SMB 2.0 protocol, Offline Files, TCP window scaling and WAN acceleration devices from various network vendors that cache and optimize SMB 1.0. 

Microsoft's modifications Microsoft added several extensions to its own SMB implementation. For example, it added NTLM Version 2 authentication because LanMan authentication and NTLM version 1 (derived from the original legacy SMB specification's requirement to use IBM "LanManager" passwords) implemented DES in a flawed manner that allowed passwords to be cracked. Later, Kerberos authentication was added too. The NT 4.0 Domain Logon protocols initially used 40-bit encryption outside of the United States of America, because of export restrictions on 128-bit encryption (subsequently lifted in 1996 when President Bill Clinton signed Executive order 13026). 

Opportunistic locking In the SMB protocol, opportunistic locking is a file locking mechanism designed to improve performance by controlling caching of files on the client. Contrary to the traditional locks, OpLocks are not used in order to provide mutual exclusion. The main goal of OpLocks is to provide synchronization for caching. There are 3 types of opportunistic locks: 


Batch Locks Batch OpLocks were created originally to support a particular behavior of MS-DOS batch file execution operation in which the file is opened and closed many times in a short period. This is an obvious performance problem. To solve this, a client may ask for a OpLock of type "batch". In this case, the client delays sending the close request and if a subsequent open request is given, the two requests cancel each other. 

Exclusive Locks When a client opens a file hosted on an SMB server which is not opened by any other process (or other clients) the client receives an exclusive OpLock from the server. This means that the client may now assume that it is the only process with access to this particular file, and the client may now cache all changes to the file before committing it to the server. This is an obvious performance boost, since fewer round-trips are required in order to read and write to the file. If another client/process tries to open the same file, the server sends a message to the client (called a break or revocation) which invalidates the exclusive lock previously given to the client. The client then flushes all changes to the file. 

Level 2 OpLocks If an exclusive OpLock is held by a client and a locked file is opened by a third party, the client has to relinquish its exclusive OpLock to allow the other client's write/read access. A client may then receive a "Level 2 OpLock" from the server. A Level 2 OpLock allows the caching of read requests but excludes write caching. 


Breaks In contrast with the SMB protocol's "standard" behavior, a break request may be sent from server to client. It informs the client that an OpLock is no longer valid. This happens, for example, when another client wishes to open a file in a way that invalidates the OpLock. The first client is then sent an OpLock break and required to send all its local changes (in case of batch or exclusive OpLocks), if any, and acknowledge the OpLock break. Upon this acknowledgment the server can reply to the second client in a consistent manner.