remeber to re-enable the firewall of the client when finished. (salt "client" firewall.enable)
you will need to create uvnc folder (get it from UltraVNC portable builds) folder in your Salt master, in /srv/salt
I'll add a note for clarity given the title... SaltStack does not do authentication like AD does. AD does not do patching of any sort like Salt does. Salt is an alternative to common myths about AD functionality, but not to actual AD functionality. But you can use Salt to do distributed local authentication management, which does replace the need for AD, but is very different than what is being discussed here. In this case Salt is replacing GPO, not AD.
I guess a big question is, with Nethserver is.. does it "just work" or is there a setting that needs to be selected? Not sure if this is the default behaviour or not.
Mostly this. I haven't done anything with it yet and before I invest the time, I'd like to know if it possible and/or how difficult it is, especially since a co-worker claims that it did not and he went with IIS to get the same task done (and then he sat there cursing the whole day because he doesn't like Microsoft products).
Sorry, I think we're interpreting the word cluster differently here. When I read that I though you were talking about Microsoft Cluster Server - which is a different technology than multiple domain controllers. He had three domain controllers.
In that case, how do you recover from something like this? Since the FSMO roles are on a 2003 server, do you start running through the various esentutl.exe commands?
Right, I'm talking about an AD application cluster (the set of domain controllers for one domain.) SBS has to be the root controller in order to work. And if you have a cluster (this isn't AD specific but is a general thing about clustering) you can't do restores. If you restore a cluster node like this, you corrupt the entire cluster in many cases, if you are lucky just one node. AD DCs form a database cluster under the hood, which is how they handle failovers, but that means that you have to protect them like a normal database cluster and let them resync from a rebuild, never do a restore.
Hrm, fast-clone. Probably time to try out a Btrfs based file server at home.
It's good stuff.
Yeah, I know brtfs is the way to go, I just haven't tried it out yet myself. Starting out on IRIX with XFS back in the day makes me a too nostalgic.
I still use XFS for everything.
When will be the right time to switch to btrfs then? We know it's been stable for long enough that it's becoming the default in a number of distributions now, but has it really been battle tested well enough yet?
Also, should we maybe make another thread for the btrfs discussion?
The answer here is you do not switch. You install a distro letting it do its native thing by default and less you have an over arcing huge reason to override defaults. So you will get this when you install a new system that now has it as a default.
openSuse, for example, has had it as default for two years.
Really though, I prefer XFS for anything that isn't a storage machine. VMs need something mature, stable and light. XFS does that well.
But does your preference mean that you will override a default installs choice just because that is your preference?
Using anything but default should have very clear reasons because the first time somebody besides you have to troubleshoot it there will be big problems.
I would often, yes actually. XFS is not like an odd, unsupported option. It's just not the default. It's still completely core to openSuse's design. They simply had to pick which one they were going to use when someone did not choose one or the other and they opted for extra features over lean design for those that don't know which they want, which I think makes sense. Just like CentOS opts for the simplicity of using root for administration instead of sudo, but makes it super easy to enable sudo. It's not default, but it's fully supported. They just had to choose something as default.
No substantial changes have been made during the last couple of weeks. Just a few new users and password changes plus maybe 2 or 3 new machine accounts. Some clients and servers now refuse to authenticate users during login due to the well known "trust could not be established between..." error.
Where you still getting those errors after you powered down the broken DC? I'm guessing not since you moved forward with the install of another DC.
Nope. Only "missing that other DC" errors now, which is fine. I've got some crappy internet connection (free WiFi in the train, next to no 3G/4G signal) here and can't check the current state. but it was fine half an our ago.
OK, reading your OP, it seemed that you were getting those errors after turning off the broken DC, but since you're not - seems like you found a good solution.
Hello Guys, I seem to have found the solution to this issue. By default, Azure has no ports open and that was why i was getting the errors. To solve this problem, i had to create an endpoint for the Virtual machine that had Spiceworks installed in it and open ports 389 and 636 TCP.
Now spiceworks syncs and authenticates with the AD on Azure and on premise.
that's why I was asking for specific VPN details. A VPN on the servers bypasses the Azure ports. A site to site VPN hits the "outside" of the servers and has ports blocked.