Best posts made by Joe Schmitt

I could see us adding a warning if a node cannot connect. However, I am in agreement with @Tom-Elliott that straight up preventing credential entering would cause more issues than it would solve.

@x23piracy a windows service can impersonate one of the logged in users without their password. Essentially the service grabs a process running as the user you wish to impersonate, and obtains a handle on the process’s access token (OpenProcessToken). The service then needs to duplicate the token so it can “impersonate” the user without affecting the process we lifted the token from (DuplicateToken), activate that token, and then perform the work. Finally the token handle must be closed.

Its a pretty win32 api heavy approach. The client does not use this technique as there is no guarantee a user is logged in at any given point.

TL;DR: grab an existing process running as that user, and perform multiple win32 API calls to impersonate that user.

@fry_p perhaps it is the network path option I suggested? Is your network share setup for public anonymous read access?

@ibloss

service/Post_Stage3.php is called on the server side when a client finishes imaging.

@amerhbb said in Active Directory Join Failing:

this image is already join domaine but when i deploy this image the cliens arn’t in AD ???

Images should not be joined to Active Directory as it can cause many issues. An image should be unjoined, and after deployment, the computer should then be joined (using the client or a custom script).

@ITSolutions just throwing my 2 cents in here. Do not use plain text password hard-coded into a file. In the next version of the client we could easily add a checkbox to snapins “Hide snapin details in fog.log”. With that you could make the password a parameter to the batch script. For example:

RunWith: cmd.exe
RunWithArgs: /c
File: MyBatchScript.cmd
Args: MyPassword

Snapin configuration is transmitted in a secure median whereas the file itself is obtained via a simple http download and then a sha512 is generated and compared against a security transmitted checksum to ensure integrity. Now if you really wanted to be secure you’d also need to disable the legacy client support as a potential attack vector would be to make the legacy client API calls before the new client has a chance to grab the snapin information, thereby giving it in plain text. I’m not sure if we have such a checkbox to disable the legacy client yet so pinging @Tom-Elliott.

Another option:
Bake in your user share password into some SYSTEM read-only file on your image and make your batch script read it for the credentials.

@johnomaz , a couple quick notes:

1. Handlers.dll will not exist in newer version of the client, FOGService.exe is the safest file to check for.
2. Any setting you see in the MSI can be set via CLI arguments. For example, to set the server address, just append WEBADDRESS=“x.x.x” to the install command.

@boyan-biandov that is certainly strange and I’ve never seen it happen before. I’m not sure what you’ve tried so far, but here’s a couple ideas to hopefully at least workaround the issue:

• Try copying c:\users\Administrator\AppData\Local\Packages\windows.immersivecontrolpanel_cw5n1h2txyewy to C:\Users\Default\AppData\
• I suppose you could use Logon script via GPO to also manually copy over that folder every time

Would you also be able to share your unattend file? Feel free to strip out any sensitive information in it.

If you are able to run those scripts manually (with $ UNC paths), than would be a restriction of running as SYSTEM. There is nothing the client can do about this.

@RLane As long as you are only using the legacy client with your current server, you are good to go. No need to transfer over your certificates.

@Joe-Gill can you attach the C:\fog.log from one of the problematic machines?

v0.11 of the client should prevent this. The FOG Service will have a dependency of dnscache which is Window’s DNS Client. The DNS Client is one of the last network services to start and all version of Windows within reason use it.

@Rusty

Here’s my two cents. When it comes to software, have general software pre-installed, and then use snapins to deploy specialized software.

When it comes to the universal image, I have made an image which was only 5GB or so larger that included a lot of drivers. It worked on all the models I had at my disposal (ranging from netbooks, to laptops, to desktops). If you are interested I could try helping out making this image (its been ~1-2 years since I have done so). And if the image works then I’ll write up the steps for the driver packs / configuration I use as an actual guide. However, there is no guarantee that this image would work on all your models. It would need to be tested and probably refined a little.

If you’re interested PM me.

Fixed and v0.8.2 released

The new client requires the permissions to create an account (this is needed for samba domain support).

@cotec
The legacy client (The one shipped with 1.2.0 and below) should be Windows 10 compatible. The new client (shipped with developer builds of FOG) is definitely compatible.

Tom means that this problem is now fixed in 3685. Update your svn copy and upgrade the server.

This is not an issue with the client. I have tested snapins on r7961 with 0.10.6 and all worked perfectly. It sounds like something in your database is off. @Tom-Elliott.

As for v0.9.12 not working, anything before 0.10.0 is incompatible with the latest revisions (except legacy client which is still compatible).

I have also confirmed that “Disable auto updating” functions properly on v0.10.6.

Change Snapin Run With Args to

/quiet /i

The second log you posted, did you edit it at all? Some things are happening in it that just aren’t possible with v0.9.4.