Jtdylktuy

I will soon embark on a task of upgrading the IT infrastructure of a company's head office. I briefly considered hiring an IT administrator to do this part of the job, but after assessing what they have, I am inclined to think that may be overkill. That being said, I also don't know exactly what I'm doing and I'm trying to learn. They currently have 6 workstation computers all running windows 7 (one of which is running as a server for file sharing, among a few other things).

In preparation I've installed windows 10 professional on a spare computer I have at home and I am trying to implement the same type of setup here using whatever (probably outdated) best practices I know. But I'm running into issues already.

For example, I cannot create a user called "administrator". I had always thought that you are going to want an administrator account for all things admin and a regular user account for daily use. Yet I get an error telling me that account cannot be made. I know this can be done, as the machines at my workplace have an administrator account, but that may be something related to the domain, which I do not have.

I think all of this can be managed simply by understanding how to set up and administer a "workgroup" with filesharing from the server machine, but my first basic task of creating an administrator has already gone wrong. As it is I had to turn on SMBv1 on each machine just to get the computers to show up on the "Workgroup" in the navigator.

Can someone point me to a good and current best practices resource I can follow for setting up a workgroup with some basic features, like file sharing, etc?

This isn't a place for "best practice resources"; it's a forum for solving specific problems. (Ideally one problem per thread.)

For example, I cannot create a user called "administrator".

It already exists; see lusrmgr.msc if you want to unlock and use it. The built-in account is somewhat special, e.g. it bypass UAC, and it's recognized by the login screen as always a local (non-domain) account.

For local use, UAC somewhat mitigates the problem – even if you're logged in as an admin, you don't actually get admin access until you go through the elevation prompt ("run as administrator"). Unfortunately there's no such thing for network privileges; if you log in as a domain admin, there are no prompts or blocks whatsoever preventing malware from performing AD administration as you. So the practice is still relevant.

I think all of this can be managed simply by understanding how to set up and administer a "workgroup"

Workgroups don't actually affect accounts at all; users continue using their local accounts, and log in to servers using accounts on that server. To be clear – in Windows, a "workgroup" isn't something you separately enable, and it doesn't give you any new features. It's just the default mode of standalone (non-domain) PCs.

(Not to be confused with "workgroup name", which is a NetBIOS Browsing parameter that tells it which computers to show/discover and which ones to ignore.)

You might be thinking of domains (Active Directory), which do centralize authentication and do provide central management features (via Group Policy, etc).

Or you might be confusing workgroups with HomeGroups, which used to be an actual workgroup-oriented feature in Windows 7–8.1 that automatically configured a shared account for the whole LAN on all computers joined to the homegroup. (As the name says, homegroups were meant for home use where all machines are trusted. Homegroups were removed in Windows 10.1803.)

As it is I had to turn on SMBv1 on each machine just to get the computers to show up on the "Workgroup" in the navigator.

This is actually the last thing to deal with from the technical side – it involves the most complex protocols and is furthest away from the actual file-server connection. (For clarity, note that enabling "SMBv1" in Windows features actually enables two protocols at once – the second is the whole NetBIOS suite, and that's what gives you these features.)

1. Actually accessing another computer's files is the simplest part, all you need is regular SMBv2/3 and that computer's IP address. Open \192.168.x.y in the navigator and you have it.



2. 
   

   Accessing other computers by name needs additional protocols but still tends to be simple technically. It can be handled by DNS on your router, or by LLMNR on WinVista+, or by mDNS in Win10.1803+, or finally by NetBIOS' NBNS if you've enabled the "SMBv1" feature.

   
   
   

   This lets you use \computername in the navigator. But in the end, all it does is convert the name to an IP address, so you have to get #1 working first anyway

   
   


3. 
   

   Finally, discovering other computers requires more complex protocols and even features that the network needs to support. Windows has two protocols which can be used for this (simultaneously): WS-Discovery from the SMBv2/3 era and NetBIOS Browsing from the SMBv1 era.

   
   
   

   NetBIOS Browsing was designed for LANs in the 1990s and although it specifically tried hard to be less fragile, on modern LANs it tends to achieve the opposite result. Besides, to enable NetBIOS at all, you had to enable SMBv1 as well – and SMBv1 is considered a major attack vector even by Microsoft themselves. So you should first try to get WS-Discovery working without SMBv1/NetBIOS enabled.

   
   
   

   To do this, uninstall SMBv1 client & server again, then enable the two "Function Discovery" services via services.msc. See this Microsoft KB article for more information (scroll down to "Explorer Network Browsing").

   
   
   

   (Note: WS-Discovery and the aforementioned LLMNR may need IPv6 to be enabled on the systems. If you're disabling IPv6...don't disable IPv6.)

   
   

On a "file server" environment you don't really need to bother with discovery – people won't be connecting to each other's PCs randomly, they'll just be connecting to specific shares on your designated server. You can just make desktop shortcuts or map network drives for those.