0

I'm only running one physical server at a time (think faux cluster in power saving state). The host/hypervisor's shares which are replicated to other host/hypervisors on the domain, are home to VMs and some TB of data. One of the VMs is the DC, and the shares of the host need to be on the domain. On reboot, host's network location awareness service obviously doesn't see the domain up yet and joins public network. While the DC eventually comes up, it doesn't see the shares, as host isn't on domain. I'm not sure how to address this. The couple things I've tried haven't played out.

I've tinkered with delaying NLA and adding dependencies to the service, which didn't work.
I've tinkered with a startup script that restarts NLA, and while this probably works opening security to scripting makes me squirm.
I read about cached credentials to get the host on the domain, but unsure how this would work automatically for NLA.

What's the proper way to do this?

Improve this question
5
  • We typically make the DC also the fileserver, that way there is no issue.
    – LPChip
    Commented Feb 27, 2021 at 16:52
  • @ LPChip I'm tempted, but best practice is to not clutter/open holes in DC. Trying to keep it clean and segregated so hoping for another way.
    – geardogg
    Commented Feb 27, 2021 at 17:08
  • What exactly is the hole you open if you move files from one server to another, set shares and alter GPO to use the new location instead of the old? Unless of course you have a weird rights structure with specific rights 4 levels deep into the file structure. We keep permissions on the share and at best one level down to keep it manageable.
    – LPChip
    Commented Feb 27, 2021 at 21:37
  • @LPChip, I don't honestly know all the file sharing ports or vulnerabilities this might enable. I base my previous statement on what I've read. It always seems to be advised that you keep your DC a DC and nothing else. I take that thinking to be keeping the heart of your domain safe. I do appreciate your thinking, but I'm hoping to not have to make each of my host clone standbys in the DFS replication group a DC also.
    – geardogg
    Commented Feb 28, 2021 at 17:05
  • Well, yes, but a DC already has to act as a SMB file server for the Sysvol, so it's literally the same thing...
    – grawity_u1686
    Commented Mar 4, 2021 at 22:45

1 Answer 1

Reset to default
2

The file shares should be VMs as well.

If you're going to go VMs for your DC, then allow the host just to be the hypervisor. This has several benefits, among them that fewer roles on the system mean fewer patches to be installed so fewer restarts/maintenance windows.

So, create a VM for the file shares, then schedule the start sequence for the VMs to be DC first, wait a couple minutes, then everything else starts up in appropriate sequence, and can connect to a fully identified network.

Improve this answer
10
  • My host is the hypervisor. I'm trying to keep the host as dumb as possible so setup of clones is as simple as possible. The shares are so big it doesn't make sense to include them in the VM drive itself. Thus, if I understand the Hyper-v File Sharing model correctly, the way I'd share from a VM is to give the VM direct access to those disks within hyper-V, but that goes against the "dumb host" thinking and makes a potential migration less than slick. The shares are on a namespace to make host swapping smoother. Am I missing an obvious nuance to FS from VM?
    – geardogg
    Commented Feb 28, 2021 at 17:12
  • 1
    I don't think you understand VMs and Hyper-V particularly well. The VMs are computers. They consist of configuration files and blob storage files on the host, running within the hypervisor. The "host" being "dumb" is not a concern at all. The host being "simple" may be. Run a second VM on that same host, attache storage to it to store the shares, and move the shares to that 2nd VM. It's really quite as simple as that.
    – music2myear
    Commented Mar 1, 2021 at 1:18
  • While this was my first thought, the point of my approach is to leave minimal entanglements between host and VMs, for portability. The host is replicating the available storage, which is a necessity, as the host is part of a virtual san. As I understand it, one has to give a VM sole rights to a partition for what you describe, and that would surely interfere with the drive replication. To play along down the path of your education, I have storage attached. How do I "move the shares to that 2nd VM" without interfering with DFSR?
    – geardogg
    Commented Mar 2, 2021 at 14:34
  • VMs don't care about partitions on the host. VMs drives are all just blob files on the host. While it is technically possible to mount a given partition on the host to a VM, it's very much NOT recommended, for many, many reasons, especially on a tight enterprise setup like yours.
    – music2myear
    Commented Mar 3, 2021 at 4:15
  • There seems to be a disconnect here. I have a blob file on a host, great. That VM wants to share files that also reside on that host, but do not reside within the VM blob. You say "just move the share to the VM" and here lies my query. If I'm going to alter my design to have a VM handle the share, how? What I read says give direct partition access to the VM.
    – geardogg
    Commented Mar 3, 2021 at 14:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .