I have a Gold build image which i have used in my Task sequence 2 to create a device specific image by adding the drivers.The Gold build already has an autologon registry entry for the Administrator account which is what i want after Task sequence 2 is over but as MDT deletes any autologon entries in the registry the autologon towards the end doesnt seem to take place.
The things i have tried is commented the part in LiteCleanup.wsf which clears any Autologon entries from registry but that doesn't seem to work.
Any suggestion would be highly appreciated.
The things i have tried is commented the part in LiteCleanup.wsf which clears any Autologon entries from registry but that doesn't seem to work.
Did you update the deployment share after this modification ?
Maybe you can add a command line task at the very end of the sequence and add the registry key with this method.
Related
I have a script that deploys a WIM to a partition and makes it bootable and it uses an unattend.xml to configure the name and everything else. I include the BackInfo.exe with settings for it and when the OS boots up I have it run a logon script to initialize the OS for a bunch of stuff. I have tried in the script to run the BackInfo.exe, I have tried in the unattend.xml, I have tried adding a registry key into HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, I have tried adding a scheduled task.
No matter what happens the background is always the default one and never set to the generated one from BackInfo. When I run the command manually it works perfectly. I for the life of me can't seem to get this working.
Any help would be very much appreciated!
So turns out I had placed the code into the FirstLogonCommands section which turns out wouldn't work, I changed it over to LogonCommands.
<LogonCommands>
<AsynchronousCommand wcm:action="add">
<CommandLine>%SystemDrive%\Applications\BackInfo\BackInfo.exe</CommandLine>
<Description>BgInfo</Description>
<Order>1</Order>
</AsynchronousCommand>
</LogonCommands>
Hopefully this can help someone else in the future and prevent them from wasting time trying to figure out other ways.
I'm trying to deploy images via MDT that have been upgraded via the MDT "Standard Client Upgrade" task sequence. My images started as Win10 v1607 images and are updated to v1703 and then captured.
When I go to deploy the captured images, I'll get a popup on first login that c:\LTIBootstrap.vbs can't be found. Digging, I discovered that after the OS is installed and the PC restarts, the MDT task sequence continues running as the SYSTEM account . This is bizarre as it typically runs as the built-in Administrator account.
For some reason, even though the unattend.xml file contains the usual AutoAdminLogon entries, a registry key at
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\SystemAutoLogon
is being created and set to 1 during the deployment. (I discovered this by comparing the registries at the end of deployment.) This key is not present in the captured image. This key does not get created if I deploy an image that is manually updated to v1703 (via Windows Update instead of MDT).
Any ideas on why the unattend.xml could be ignored or what would cause SystemAutoLogon to get created and set?
I figured out what was going on.
The MDT Upgrade task sequence invokes the upgrade with the command line /postoobe option pointing to setupcomplete.cmd. This causes the file to be copied to c:\windows\setup\scripts\setupcomplete.cmd. When windows install is complete, if a file is present at that location, it is run under the SYSTEM account.
The problem is that this file remains even after the upgrade task sequence is totally complete. So if you then capture the image and deploy it to a real machine, it will see setupcomplete.cmd and run it after the deploy, instead of using the usual default Administrator account.
I imagine the presence of this file at c:\windows... is what causes the registry changes mentioned above. setupcomplete.cmd is only built to bootstrap an upgrade back into the MDT task sequence, and needs to be removed from c:\windows... when the task sequence is done running.
Knowing that the post-upgrade portion of the upgrade task-sequence runs as SYSTEM instead of Administrator via a very different mechanism than standard deployment is important, as there are then limits to what you can do. By default the sequence lets you install applications.. they need to be apps that are ok being installed by SYSTEM.
For now I've updated my local SetupComplete.cmd in my scripts directory to delete itself when it is done by changing the last for loop to this (there was also a typo in the for loop before preventing the exit echo):
for %%d in (c d e f g h i j k l m n o p q r s t u v w x y z) do if exist %%d:\Windows\Setup\Scripts\setupcomplete.cmd (
del /q /f %%d:\Windows\Setup\Scripts\setupcomplete.cmd
echo %DATE%-%TIME% Exiting SetupComplete.cmd >> %WINDIR%\Temp\setupcomplete.log)
After thinking about this more and hitting issues due to running as the SYSTEM account, I started playing with avoiding running as the SYSTEM account. (One big problem is that if you want to shutdown at the end of the task sequence right after a reboot occurs, SYSTEM starts running too fast, and the call to shutdown in MDT fails.)
The idea is to instead use SetupComplete.cmd running as SYSTEM to simply bootstrap back into running the task sequence as the default Administrator.
There are a few wrinkles to implementing this. Namely, the synchronous commands that run from unattend.xml during a normal install do not run, so things like enabling admin, disabling uac for admin, disable user account page, disable async run once all have to be invoked manually. Beyond that, it is just a matter of setting the right registry entries by calls to PopulateAutoAdminLogon and SetStartMDT via a step in the task sequence after the OS upgrade is complete, and then performing a restart. This seems to work pretty well. The ideal way to do this would be to have the same script that calls PopulateAutoAdminLogon/SetStartMDT also parse unattend.xml and run those commands.
For some reason shell hiding does not work even though everything is set for it. My best guess is that the task sequence runner is doing this because IsOSUpgrade is set, but am not sure.
With this approach, SetupComplete.cmd is just responsible for a single bootstrap back into the task sequence, and the task sequence can delete it at the same time that it calls a script to do PopulateAutoAdminLogon/SetStartMDT
There is enough work to be done to fully polish this approach that I'll just workaround the one autologin issue for now, but it really does feel like a better way for MDT to work when doing upgrades. Hopefully they'll flesh it out in the future.
I have two CentOS 6.8 servers running on VirtualBoxes.
On one, I can login as a regular user then use "sudo" to run administrator commands. I just add "sudo" to the front and all works as expected.
On the other, I need to first run "newgrp wheel", otherwise it nags me that I'm not in the sudoers file. Once that's done, all is well.
As far as I can tell, both systems are otherwise identical. The username in both cases has a primary group of "users" and is also a member of "wheel" and "apache" groups. The "wheel" group, of course, has been given "ALL" access via "visudo".
The only difference, if it's important, is that the first one is a VM on Linux, and I access it via Putty. The nagging one is a VM on Windows, and I access it via the VirutalBox screen.
It's not a very big issue, but I like not needing the extra step. Does anyone know what is going on here?
Well it turns out the systems were not as identical as I thought. The "visudo" sudoers file on the nagging version had somehow been restored to its original version, which meant that the "%wheel" directive was commented out. I only discovered that in trying to add a 10 minute timeout.
I have a problem trying to implement a mongodb replica set as a worker role instance in Windows Azure. In the Windows Azure portal, one of the instances is shown as busy with the status:
Waiting for role to start... Calling OnRoleStart()
I have checked all the settings and everything seems to be ok, what could the problem be?
Denis Markelov's blog post helped me solve this problem. The solution is mainly his, however I had to take an extra step to get it to work and thought others might find it useful.
Solution from blog:
Windows Azure reuses virtual machines for roles, so after a fresh
deployment on a hard drive you can find files that were created during
previous sessions. If MongoDB was terminated improperly - there might
be a lock file ("persisted mutex" analogue), because of which MongoDB
refuses to start. It is located at the drive with a label
"WindowsAzureDrive" (say it is F:), at the path:
F:\data\mongod.lock
In the case of a production use this situation might require a
recovery procedures, but if you are just in the process of initial
setup - it is safe to remove this file, letting MongoDB to start
again.
I was having this problem and did as suggested, however I was still having the same problem. So I took a look at the log file at
C:\Resources\Directory\.MongoDB.WindowsAzure.MongoDBRole.MongodLogDir\mongod.txt
And saw that another file was also giving an error. In order to fix the problem, you also have to delete the file local.ns in the same directory as mongod.lock.
Is there a way to hide few steps during an installation of an already existing installer? Like, hide the steps for the inputting of username or password? I want to hide these steps during the installation and run a batch file or script to set the default username or password instead.
Is there a possible way for this? How can I do this?
For example, installing postgreSQL, I'd like to hide the steps/windows for the username/password input, and run a batch file to set the username and password.
PS: I am not the author of the installer, I just want to modify it that way, if it is possible.
Thanks.
I already found an answer for my problem. It is performing an unattended installation where a user interaction is not needed anymore. Installation can be done in the command line where parameters can just be added (a config file can also be used for these parameters).
See the following links:
http://www.enterprisedb.com/docs/en/8.4/instguide/Postgres_Plus_Advanced_Server_Installation_Guide-15.htm#P889_74430
For command line options reference:
http://www.enterprisedb.com/docs/en/8.4/instguide/Postgres_Plus_Advanced_Server_Installation_Guide-17.htm#P1062_89370
Although this installation process only displays a progress bar, my problem is already solved since no user interaction is already needed. :)
I don't think it is possible to just hide particular one step from installer. Moreover AFAIK One Click Installer is only closed source, so you can't change its behaviour. However there are two alternative ways:
show visually that step, but with other default values, so user can simply click next
run installer in non-interactive mode (--mode unattended)
First of all check available options with Installation Guide and:
cmd>postgresql-9.0.4-1-windows_x64.exe --help
For example you can adjust --superaccount MyCustomizedUser --superpassword 12345 with such result (default is postgres and blank password):