Maintaining Saved Samba Mappings
-
Hi,
New to Fog. Got things working pretty decently so far. Great system.
I have a golden image of Win10 that gets sysprepped. In this image a have a user setup that I want to remain setup on each node (nodes are for a 3d render farm-- so all used by the same user, not logged into by multiple people).
I would like each node to have some stored network connections to Samba shares. I have these configured in my user on the golden image such that they are path mapped. and working correctly in the VM used to make the golden image.
After Sysprep (which I think may be the culprit) and deployment I still see these mapped drives on the newly imaged machines. However, they do not connect, sometimes saying bad passwd, sometimes saying the network is already in use.
I can manually go in and disconnect and reconnect these drives on each machine (re-entering credentials) and then everything works fine, but I would like to have things be a little more no-touch.
Any suggestions for how to keep the mapped drives working correctly on the imaged machines?
Thanks in advance.
-
@Flyer The win10/win11 OOBE/WinSetup resets a lot of things in the destination environment. I’ve found it more useful to use the setupcomplete.cmd as well as the unattend.xml first run section to do some post deployment activities like creating users and configuring profiles.
For this user account, will it be configured to auto login? If yes there are two things you can leave behind post deployment.
- Use ActiveSetup registry keys to install stuff in the (any) user profile when a user logs in. I’ll use this when creating deployment packages where the software is installed as SYSTEM, but stuff needs to be configured in the user profile to use the software. The ActiveSetup scripts are fired once, unless you update the sequence number then they will be fired a second time every time the sequence number is changed.
- You can configure a batch file to be called when a user logs in. This batch file will be executed each time the user logs in.
Do all of these persistent drive mappings post image deployment using the methods above.
-
Thanks for the reply.
Initially I was creating the user with the unattend.xml, but I think I changed because of the mapped drives. When creating form scratch they weren’t there at all. Also, there are some BG applications (like sys tray stuff) that need to run for the user to make the rendering process work. So I configured these for that user on the golden image.
The users are not set to autologin (I’d like at least to have to enter a password to login, even if the same pwd for all).
My latest experiments led be to making a batch file that I could run once as the user, but I would still have to manually enter the credentials to save the user and pass for the shares. (The option to save credentials seems to be incompatible with specifying the credentials on the command line, which is never a great plan anyway.)
Maybe this is silly, and I should just store the credentials in the batch file, as either way, the user has access to the shares anyway (and the credentials are not shared with anything else). The batch file could simply be setup as a traditional startup item script, rather than involving the deployment process.
I guess I need some further testing. And I would eventually like to try to image a dual boot win/linux system that can be remotely (via script on win or linux) reboot to the other OS.
-
@Flyer I create users in the setupcomplete.cmd batch file. That gets executed at the end of the WinSetup process and before the first login.
You can also with the unattend.xml file define an auto admin login process for a specific user. You can set up a counter so the auto login process only executes X times then reverts to login required. This is configured in the unattend.xml file. There is also a first run section where you can do things to update the user’s current profile.
So the idea would be to have the setupcomplete.cmd file create the user with a predefined secure password, then in the unattend.xml file have this user account setup to auto login once or twice depending on what you need, then have the first run section do what is needed to the user’s profile.
One of the last steps in the unattend.xml file is to delete the setupcomplete.cmd and the unattend.xml to erase any clear text passwords that might be contained within. Finally reboot the computer.
These are just ideas on alternate ways to go about solving this problem. I agree that accounts you create before should still exist after winsetup, but M$ typically has other ideas for us.
