On a dynamic agent, I'm running a File Transfer job using Windows protocol.
The file transfer to my Windows system always fails.
The job goes in ABEND and the following error is reported
AWKFTE007E An unexpected error has occurred. The following error was
returned: ""CTGRI0011E An error occurred when accessing the remote
registry or service control manager." target machine.
Do I miss any setting in the job definition, on TWS or on the target machine?
The error is not due to a wrong job definition or a missing configuration
on TWS side.
It is necessary to verify these three things on the Windows target system:
verify that the user can login to the remote Windows machine (make sure that user and password in the job definition are correct)
verify that Remote Registry service is started on the Windows system (Open the Administrative Tools Control Panel, Open Services and make sure that the Remote Registry service is running)
LocalAccountTokenFilterPolicy registry key is set to 1. Open the Registry Editor and navigate to
HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/Policies/System.
Make sure that the key LocalAccountTokenFilterPolicy exists, otherwise cretae it as New Dword, and set its value to 1.
After these steps I've rerun the File Transfer job and it completed successfully. Windows system reboot was not required in my case.
Related
Trying to change password for the Workload Scheduler user, by using the changePassword.bat wastool:
changePassword.bat -user tws94mdm -password mypassword
in the generated output, the following error messages are present:
ERROR : install service <tws_tokensrv_tws94mdm> failed
System error <430>
The specified service has been marked for deletion.
"IBM Workload Scheduler Token Service (for tws94mdm)" service updated
ERROR : install service <tws_maestro_tws94mdm> failed
System error <430>
The specified service has been marked for deletion.
"IBM Workload Scheduler (for tws94mdm)" service updated
All the Workload Scheduler services are marked for deletion, with the exception of the IBMWAS85Service.
When the master machine is restarted, all processes are deleted and the master instance is unusable.
Possible causes of the problem are:
One of the following applications is opened:
SysInternals' Process Explorer
Task Manager
Microsoft Management Console (MMC)
Services console
Event Viewer
The key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services{service name} does exist
Someone else is logged into the server and has one of the previously listed applications opened
In case the changePassword tool fails due to a service marked for deletion, you must restart the server and rerun the changePassword tool in the wastool folder to recover the master instance.
I have a Windows 2008R2 server in GCE that is behaving oddly (may be compromised). I can no longer access it via RDP. When I reboot the machine and look at the serial console, I see at the very bottom after the boot sequence, that something called Credentials Manager runs and appears to delete or change some username/password. I suspect that this is what is changing the RDP password. (see image attached). On a normally running Windows VM, I do not see this in the trace.
GCE Agent started.
Starting AddressManager
Starting CredentialsManager
Credentials have changed. Updating...
Changing username...
Deleting old user...
Username or password was updated successfully.```
I have tried resetting or adding a new password using the metadata windows-startup-script-cmd = net user but that does not seem to do anything.
What I get is an error message of the form:
Booting on date 05/05/2015 10:22:49
WARNING: Computer Name windows does not match Compute Engine Instance Name XXXXX.
Did you forget to run gcesysprep?
attributes/windows-startup-script-bat value is not set or metadata server is not reachable.
attributes/windows-startup-script-ps1 value is not set or metadata server is not reachable.
So the question is, how can I get into the machine to see what is happening? Is there a way that the GCE startup sequence could be changed to not call the credential manager to change the password or username?
What you could do is if you have a Gcloud SDK (https://cloud.google.com/compute/docs/gcloud-compute/) installed, you can run the following command while that instance is running:
gcloud compute instances decribe instance_name
This will provide all the information about the instance and you will see a section called MetaData which will display the users and the passwords. Then you can try to remote in and remove any credentials setup in the Credentials Manager located in Control Panel -> User Accounts.
I hope this give you access to your VM
I have spent days trying to find a way to save users' open Excel 2007 files before a shutdown.exe or psshutdown.exe is issued. I'm using Windows 7 Pro 64-bit machines w/UAC enabled, including remote restrictions. I don't want to bypass these security measures.
I have developed vbscript that can do the job, but it only runs locally. The code is shown below:
Option Explicit
'--------------------------------------------------
'*** Dimension Local Variables ***
Dim objXL, msg, i, WshShell, strShutdownMessage, strMsg
'*** Enable Error Handling ***
On Error Resume Next
'*** Display Server Emergency and Computer Shutdown Message ***
Set WshShell = WScript.CreateObject("WScript.Shell") 'Creates an instance of the Windows Scripting Host shell (WshShell)
'--- Popup Message - Automatically Closes After 15 Seconds ---
'--- (the "4112" nType value is the sum of 16 - Critical window type + 4096 - display on top!!)
WshShell.Popup "AN UNEXPECTED SERVER EMERGENCY HAS OCCURRED." & Chr(13) & Chr(13) &_
"THIS COMPUTER WILL AUTOMATICALLY SHUT DOWN 30 SECONDS FROM WHEN THIS MESSAGE DISAPPEARS. " &_
"PLEASE SAVE YOUR DATA AND CLOSE ALL OPEN APPLICATIONS IMMEDIATELY!", 15, "SERVER EMERGENCY SHUTDOWN WARNING!",4112
'*** Debugging Exit ***
'WScript.quit
'*** Wait 30 Seconds Before Saving Data, Closing Applications, and Shutting Down Computer ***
WScript.Sleep 30000
'*** Set Excel Object Variable ***
Set objXL = GetObject( , "Excel.Application")
'*** Trap Error And Shutdown Computer If No Open Excel Workbooks ***
If Err.Number > 0 Then 'No open Excel workbooks
'MsgBox ("ErrorLevel ... = " & Err.Number)
'Wscript.quit
WshShell.run("c:\windows\system32\shutdown.exe /f /s") 'Run shutdown command
End If
'*** Save Data And Close Each Open Excel Workbook ***
For Each i In objXL.Workbooks 'Close each open Excel workbook
i.Save
i.Close
Next
'*** Shutdown Computer ***
WshShell.run("c:\windows\system32\shutdown.exe /f /s")
The problem I'm having is that a 429 error is thrown when the code executes the following statement:
Set objXL = GetObject( , "Excel.Application")
I have tried psexec, runas, vmrum (the remote machine is a VM), and even the Task Scheduler to work around this problem. I even figured out how to determine the session number of the logged-in user on the remote VM so I could pass it to psexec so it could run interactively with the remote VM user. The shutdown warning message shows up correctly on the remote VM active user's desktop. But I always get the 429 error - unless I'm logged on at both the local and remote computers with the remote VM's local Administrator account (this is a workgroup, not a domain, BTW). I initially thought it might be a psexec problem, but I now think it's either an Office 2007 or Windows 7 UAC permissions issue (thanks Harry Johnston in an answer to my original post):
GetObject() 429 Error When Using PSExec To Run WScript File On Virtual
Machine
Is there some way to save open Excel files on a remote machine BEFORE a shutdown is issued? I don't trust the Office AutoSave. My clients' data is too important to lose in a power outage or due to their inability to use AutoSave properly.
If you shutdown normally, Word et al will pop up dialogs. A normal shutdown is merely a request for programs to close, any program can cancel it. When forced programs are terminated.
Therefore do a normal shutdown of excel in the clients. They will get a dialog. They can cancel it too. taskkill command line program can do this.
taskkill /s computername /im excel.exe
If they refuse to close you can usethe /f flag to force closing.
The short answer to this problem is that the vbscript I ran on the remote machine was not being run within the security context of the remote machine's logged-on user. Because of this, Office 2007 wouldn't allow the creation of the objXL object from the Excel.Application ActiveX component (hence the 429 error message, "ActiveX component cannot create object") in the following line of code:
Set objXL = GetObject( , "Excel.Application")
The challenge, then, was to be able to figure out how to run my vbscript (or any application, for that matter) within the security context of the remote machine's logged-on user. I ultimately settled on PSEXEC as the utility that I use to run my vbscript on the remote machine. PSEXEC has three issues that I had to deal with in order to get my vbscript to execute successfully without the 429 error (if you use something other than PSEXEC your list of issues may be different). These issues exist ONLY on the remote machine:
The Remote Procedure Call (RPC) Engine is not activated
UAC remote access restrictions are enabled
Applications MUST run in the logged-on user's Windows 7 session
Solving the first issue requires enabling the RPC Engine on the remote computer. To do this you have to configure and start four (4) Windows services AND configure a registry key to enable remote RPC. Configure the registry key to enable remote RPC as shown below:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer
AllowRemoteRPC ... dword = 1
fDenyTSConnections ... dword=0
The four Windows services should be configured as follows:
Remote Desktop Configuration service ... manual start ... MUST BE STARTED
Remote Desktop Services service ... manual start ... MUST BE STARTED
Remote Desktop Services User Mode Port Redirector service ... manual start .. MUST BE STARTED
Remote Procedure Call service ... automatic start ... MUST BE STARTED
The second issue, UAC remote access restriction, prevents any user with an account on a Windows 7 machine from accessing the machine remotely using remote PRC (which is the mechanism used by PSEXEC to run applications on remote machines) EXCEPT WHEN USING THE MACHINE'S BUILT-IN ADMINISTRATOR ACCOUNT. The Windows 7 built-in Administrator account is not affected by UAC remote restrictions (this explains why my vbscript executed without the 429 error when I used the Administrator account). However, every other user account is affected.
After days of testing I learned that applications can only be successfully executed on a remote machine if they are run within the security context of the remote machine's logged-on user. That means that PSEXEC must use the login credentials of the remote machine's currently logged-on user in order for the application to access the security context of the remote machine's logged-on user and not throw the 429 error. This was the key piece of learning that helped me configure this solution to solve the 429 error problem.
But how could I use the remote machine's logged-on user's login credentials (assuming I had some way to obtain the credentials; more on this later) to execute my vbscript within the security context of the logged-on user if the remote machine's UAC remote access restrictions denied me access to the remote machine in the first place? The only way I could get this to work was to turn off the remote machine's UAC remote access restriction. This was not a trivial decision, because turning off UAC remote access restriction opens up the remote machine to "loopback attacks." But I had no other option if I was going to get PSEXEC to run my vbscript on the remote machine in the security context of the remote machine's logged-on user. To turn off the UAC remote access restriction, modify the following registry key on the remote machine:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
A value of "0" (zero) ENABLES UAC remote restriction; a value of "1" DISABLES UAC remote restriction. Change this value to "1" to DISABLE the UAC remote access restriction. This will allow PSEXEC access to the remote machine to use the login credentials of the remote machine's logged-on user to run its application payload.
The final, and most challenging issue, was how to determine which user was logged-on at the remote machine, then use their username and password to run PSEXEC within the logged-on user's security context. The solution to this problem was to use QWINSTA to query the sessions data on the remote machine. This involved creating a Windows 7 command (.cmd) file that interrogated the remote machine using QWINSTA and determined which USERNAME was associated with the remote machine's Active session along with the ID of the Active session.
Using a series of DOS compare ("==") statements present within the Windows 7 .cmd file, the QWINSTA USERNAME value is compared to a list of remote machine users and their passwords to determine the remote machine's logged-on user's password. The username, password and session ID are then passed as expanded DOS variables to the PSEXEC statement. The PSEXEC application payload can then be run on the remote machine in the correct user session (this was also a tough problem to solve), with the logged-on user's credentials. It's the combination of correct user session and logged-on user login credentials that "connects" the PSEXEC application to the logged-on user's security context and allows it to run without generating a 429 error.
I'm curious to know the order of Windows startup during a user login. Does anyone know?
Basically, my application was being invoked by login script that a GPO calls. While 3rd party EXE was being invoked, it was failing to start.
Then, through trial and error, I found that HKCU...\RunOnce keys execute after the login script. Same result, the EXE was being called, but failing to start.
What worked: updated the login script create a shortcut in the user's Startup folder. Now the EXE starts up as expected.
I know that AutoRuns can tell me all the locations where startup items can be placed, does anyone know the execution order as a whole? I was able to find that Run and RunOnce keys get called asynchronously. I can keep testing each startup item that AutoRuns states, but this could take days.
I'm mostly interested in Windows 2003 Server login startup flow, but I would suspect its very similar to other Windows flavors in use today.
Source: Understanding the Startup Process - Windows 7 Tutorial
The normal startup sequence for Windows 7 is:
Power-on self test (POST) phase
Initial startup phase
Windows Boot Manager phase
Windows Boot Loader phase
Kernel loading phase
Logon phase
Kernel Loading Phase The Windows Boot Loader is responsible for loading the Windows kernel (Ntoskrnl.exe) and the HAL into memory.
Together, the kernel and the HAL initialize a group of software
features that are called the Windows executive. The Windows executive
processes the configuration information stored in the registry in
HKLM\SYSTEM\CurrentControlSet and starts services and drivers. The
following sections provide more detail about the kernel loading phase.
Logon Phase
The Windows subsystem starts Winlogon.exe, a system service that
enables you to log on and log off. Winlogon.exe then does the
following:
Starts the Services subsystem (Services.exe), also known as the SCM. The SCM initializes services that the registry entry Start
designates as Autoload in the registry subkey
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Servicename.
Starts the Local Security Authority (LSA) process (Lsass.exe).
Parses the Ctrl+Alt+Delete key combination at the Begin Logon prompt (if the computer is part of an
AD DS domain).
The logon user interface (LogonUI) feature and the credential provider
(which can be the standard credential provider or a third-party
credential provider) collect the user name and password (or other
credentials) and pass this information securely to the LSA for
authentication. If the user supplied valid credentials, access is
granted by using either the default Kerberos V 5 authentication
protocol or Windows NT LAN Manager (NTLM).
Winlogon initializes security and authentication features while PnP
initializes auto-load services and drivers. After the user logs on,
the control set referenced by the registry entry LastKnownGood
(located in HKLM\SYSTEM\Select) is updated with the contents in the
CurrentControlSet subkey. By default, Winlogon then starts
Userinit.exe and the Windows Explorer shell. Userinit may then start
other processes, including:
Group Policy settings take effect Group Policy settings that apply to the user and computer take effect.
Startup programs run When not overridden by Group Policy settings, Windows starts logon scripts, startup programs, and services
referenced in the following registry subkeys and file system folders:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Runonce
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
SystemDrive\Documents and Settings\All Users\Start Menu\Programs\Startup
SystemDrive\Documents and Settings\username\Start Menu\Programs\Startup
Several applications might be configured to start by default after you
install Windows, including Windows Defender. Computer manufacturers or
IT departments might configure other startup applications.
Windows startup is not complete until a user successfully logs on to
the computer. If startup fails during the logon phase, you have a
problem with a service or application configured to start
automatically.
If you want further information check the source link.
I have a script written in Visual Basic that starts a process (given to the script as an argument) on a remote system (again, given as an argument) using WMI. This script works fine when using an Administrator account on the remote system, but when using a non-administrator account, I get the following error:
ConnectServer Failed w/ (-2147024891) Access is denied.
I'd like to be able to run processes on remote systems as a non-administrator user with this script, and I'm pretty sure the problem is due to security settings on the remote system, but I've not been able to reset the right ones.
It sounds like you need to configure launch and activation permissions for this user, on the target machine, via DCOMCNFG. By default non-admin users do not have remote launch and activiation permissions.
Alternatively, depending on the operating system you are connecting to, there may be a "Distributed COM Users" group to which you can add your user. This group already has the appropriate permissions. The Distributed COM Users group was first included in Windows Server 2003 Service Pack 1 (DCOM Security Enhancements).
You can read more about WMI and DCOM permissions here. More detailed steps on how to configure WMI and DCOM are included in the serverfault thread Which permissions/rights does a user need to have WMI access on remote machines?.