@Troye-Johnson said in SnapinPack not deploying:

Yes I am aware it runs as system. The script has credentials embedded for network access, but it does not seem to even be making it that far is there a wasy for me to ensure the zip is being downloaded extracted and ran?

Per my first post:

I’d recommend debugging the script by making it log to some file such as C:\pdqman_deploy.txt to ensure its running, and track down which command isn’t working.

@Troye-Johnson you need to keep in mind snapins run as SYSTEM . This usually results in some permissions issues. I’d recommend debugging the script by making it log to some file such as C:\pdqman_deploy.txt to ensure its running, and track down which command isn’t working.

@Rees107 we need more information. What server version? Do you have the newest FOG Client installed? If so we need the fog.log which can be found a problematic host at C:\fog.log.

@dylan123 said in Adding Machine to Domain using Active Directory:

So I’ve attempted to deploy an image onto the domain

Images should never be pre-joined to the domain, Active Directory is fundamentally incompatible with handling that scenario. Either use setupcomplete.cmd in sysprep to join the domain, or the FOG Client.

@Joe-Gill the second one is caused by a bad security token (a reset encryption would fix it). Your first one is somehow unpinned, that is, something removed the servers certificate from the machines keystore. The only way to fix that is a complete reinstallation followed by a reset encryption.

@Tom-Elliott there appears to be some scenario where the server’s copy of the security token is becoming out of sync with the client evident by the numerous users having to reset encryption.

@oraniko you need to keep in mind the client runs as Windows service, which gets run as SYSTEM (that is, a non-interactive user). This means you’ll need to take non-supported approach to get this working. Change
net use r: \ph.ph.biu.ac.il\Programs MYPASSWORD /user:DOMAIN\MYUSERNAME
to
net use r: \ph.ph.biu.ac.il\Programs MYPASSWORD /user:DOMAIN\MYUSERNAME /persistent:yes

Now, you need to keep in mind SYSTEM now owns this network mapping, and so only SYSTEM can remove it. In addition, Microsoft doesn’t really support this, so its likely the drive will show as disconnected for all users, but it should still be accessible if they try to open it.

Perhaps a better approach would be to make a GPO logon script to auto mount these network shares.

@oraniko if you use a Snapin Pack like you are now, then you can directly call the exe. @KnightRaven was talking about if you used just a regular snapin and hosted the office files on a network share.

@oraniko said in office snapin problem:

and the office is not being installed on the target machine.
another thing is that when i click to see the snapin, then the snapin pack template is changed to the default option, when i try to switch it back to EXE and press on update, it change again to the default option “pease select an option”

Templates don’t “stick”. That is, when you click a specific template, it just sets the fields to some defaults, and that’s it. It doesn’t remember which template its using since you could change any one of those fields.

@jmeyer said in Reg Query with 0.11.11 client:

\\console\wsusclients

When using network shares with the FOG client you have to take extra steps. More than likely your share is restricted to AD bound computers. While technically the computer running the script may be bound to that domain, the client runs as SYSTEM, which is the local, unbounded, machine. Your best bet would be to create an anonymous read/write share, or mount the share using RunWithArgs and setting Hide.

@cajos001 from a FOG perspective it doesn’t make sense to manage USB printers. If that printer is connected locally, its up to that computer to add it which could be done via Snapins but is still something FOG will not manage. If its connected to a server, its up to share it via some kind of system (CUPS, TCP/IP, Network …), which is definitely outside the realm of what FOG does.

Is it only not starting after imaging? If so is your image syspreped? Did you follow the sysprep guide with client in the wiki?

@justeverything at this point it’s a matter of debugging the script. Personally I’d have it use a log file somewhere (keep in mind it runs as root, so you can place it anywhere outside of the client tmp dir). Start with basic stuff like logging on script start, just to make sure it’s actually getting run.

@ryan-mckenzie two things:

1. The legacy client is meant to be replaced with the new client, especially on Windows 10 due to security and compatibility reasons. We do not support the legacy client on Windows 10, nor will we. Infact we plan on discontinuing all support for the legacy client in the near future. We left compatibility in 1.3 simply to help people transition to the new client.

2. It says the module is disabled. So either the modules got disabled on the FOG server for that host, or there’s some bug in RC10

The first place to look for client issues is your c:\fog.log file on the problematic host.

@cronkm whichever one is in the default ubuntu repositories, which the commands I provided will switch you to.

@cronkm it seems to be an issue with newer builds of mono (https://forums.fogproject.org/topic/9638/join-active-directory-using-fog-on-ubuntu-linux ). You’ll need to:

• Uninstall the client
• sudo apt-get remove --purge mono-complete
• sudo rm /etc/apt/sources.list.d/mono-xamarin.list
• sudo apt-get autoremove
• sudo apt-get update
• sudo apt-get install mono-complete
• Install the client

Explanation what’s going wrong:

The client using a security practiced called certificate pinning; that is, on installation it “pins” your FOG Server’s certificates to ensure it will only communicate with your specific server. Now Inorder to do this something called a “keystore” is needed, this is where the client places the pinned certificate. Unfortunately this tends to be broken on newer operating systems that mono has not yet accounted for, and in our experience it tends to be a low priority for them.

@x23piracy the default configuration / ssl cert is limited to just the IP of the fog server usually. You can edit the apache config / use your own certificate by using the config we make as a template.

@x23piracy FOG 1.X already installs with https support (defaulting to an SSL key generated by your FOG Server CA). Just change the url in your address bar to https, and assuming you aren’t running a custom apache/nginx configuration you’re set.

@x23piracy the client certainly has the capability to do what you’re asking, infact it already has the internal API built to manage the Window’s registry. However, this is definitely beyond the scope of what we’re will to add to 1.X due to the needed server changes. With that said, this would be a fairly straight forward FOG 2.0 plugin, when its ready.

In the mean time, like you already said, snapins are your best bet.

@x23piracy unfortunately a standard Active Directory contains usually just: hostname, and sid, along with a few other details such as OS version. FOG 2.0 doesn’t rely on MAC addresses as a primary identifier anymore, but still requires some additional information that’s not stored in AD to perform proper host matching. So long story short; no we will not support AD importing for the foreseeable future due to some technical limitations.