• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login

    Fog Client Disjoin From Domain Feature

    Scheduled Pinned Locked Moved
    Feature Request
    4
    7
    1.7k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • L
      LJedi
      last edited by

      Hi all, I was wondering if in the future the Fog client will be able to disjoin computers from the domain. I think that this will be helpful if computers need to be moved from one location to another or if a disjoin/rejoin will resolve PC issues when a disjoin/rejoin is needed. Thanks.

      Wayne WorkmanW george1421G 2 Replies Last reply Reply Quote 0
      • Wayne WorkmanW
        Wayne Workman @LJedi
        last edited by

        @LJedi It will un-join and then join to another domain automatically if you specify a different domain. Currently there is no feature to just un-join.

        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
        Daily Clean Installation Results:
        https://fogtesting.fogproject.us/
        FOG Reporting:
        https://fog-external-reporting-results.fogproject.us/

        L 1 Reply Last reply Reply Quote 0
        • george1421G
          george1421 Moderator @LJedi
          last edited by

          @LJedi The join will take care of a broken trust relationship. The issue that you might run into is that the fog join only reconnects the computer to AD and does not move the target to a new OU (I may be wrong on that bit, its been a while since I use the fog client to connect computers to AD).

          For example if you have a computer in a disabled OU and then image a computer FOG will activate the account, but the computer will remain in the disabled OU. I have this same issue with having the unattend.xml file connect the computer to AD. I worked around this issue with a first run command that calls a vbscript to move the computer to the proper OU on first login. I also do this for a new computer, we build new computers in a build up OU that has no GPO policies and then once imaging is done the vbscript moves the target computer to the proper OU.

          Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

          Wayne WorkmanW 1 Reply Last reply Reply Quote 0
          • Wayne WorkmanW
            Wayne Workman @george1421
            last edited by

            @george1421 You can specify what OU a computer goes into.

            Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
            Daily Clean Installation Results:
            https://fogtesting.fogproject.us/
            FOG Reporting:
            https://fog-external-reporting-results.fogproject.us/

            1 Reply Last reply Reply Quote 0
            • L
              LJedi @Wayne Workman
              last edited by

              @Wayne-Workman Can Fog join to a Workgroup instead of a Domain?

              1 Reply Last reply Reply Quote 0
              • J
                Joe Schmitt Senior Developer
                last edited by Joe Schmitt

                @LJedi nope. While the client has the internal ability to unjoin a domain, there is no present way for the server to instruct the client to do so. Let’s say AD is disabled for a client in the gui. You would expect that the client would leave AD alone then (that is, if a machine is in a domain ,leave it in that domain, and if its not in a domain, leave it out of a domain). So to have some unjoin ability, we’d need some new checkbox such as “Prevent from being added to a domain” but that could be quite … annoying? I’ve heard stories of people trying to rename a computer by hand only to have the FOG client rename it back and not be too happy. Could you imagine if the FOG client stopped manual domain joining? How easy that would be to overlook in a host’s setting?

                So the next logical progression would be: Could there be an on-demand unjoin task? That is, you can schedule a host to unjoin a domain the next time it checks in, and afterwards the task “clears” (so it doesn’t unjoin the next cycle). I suppose we could implement that, but that may end up being quite a bit of work on the server side (not sure on this since I work on FOG 2.0 and the FOG client, not 1.3.X’s backend or frontend). What you could do I suppose you could do is just make a snapin to unjoin a computer (quite easy with powershell) and have that snapin set to restart on completion. That would simulate the above feature using the current code base.

                Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                Wayne WorkmanW 1 Reply Last reply Reply Quote 0
                • Wayne WorkmanW
                  Wayne Workman @Joe Schmitt
                  last edited by Wayne Workman

                  @Joe-Schmitt said in Fog Client Disjoin From Domain Feature:

                  Could there be an on-demand unjoin task?

                  Powershell can do that. Why make a custom task? It can be done with a simple snapin and powershell file.

                  Although I suppose even that is easy to overlook, because if it’s left associated, it’ll run on next image deployment and might un-do the client’s work, causing the client to join the domain twice, and reboot twice as much as it already is.

                  Bottom line I guess from this thread and multiple others of similar nature is pay attention to what you’re doing, and what’s going on in your environment.

                  Things can be implimented and safeguarded, but too much of that hinders everything else.

                  Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
                  Daily Clean Installation Results:
                  https://fogtesting.fogproject.us/
                  FOG Reporting:
                  https://fog-external-reporting-results.fogproject.us/

                  1 Reply Last reply Reply Quote 0
                  • 1 / 1
                  • First post
                    Last post

                  157

                  Online

                  12.0k

                  Users

                  17.3k

                  Topics

                  155.2k

                  Posts
                  Copyright © 2012-2024 FOG Project