I'm trying to deploy an operating system to a target machine via SCCM.
Unfortunately, there are errors in the deployment process and as a consequence, the target machine has not received the operating system correctly.
In order to ascertain what errors are occurring in the deployment process, I wish to view log file(s) for errors. These errors are invariably located in the SMSTSLog file on the target machine.
In given the fact that the target machine is not booting, how can one copy the SMSTSLog from the target machine onto an external USB key in order to view that log file for various errors on another computer?
Plug in into the target machine the USB key which contains the
task sequence for deployment .
Press F12 (Dell machines) to load the boot options.
If it's a legacy boot then choose the USB Storage which contains the task sequence.
or
If its a UEFI boot then choose UEFI option.
For help in identifying which boot option, look at the memory size of the mounted external memory on the boot list.
If the size listed is similar to the size of your USB stick (e.g. UEFI: Jetflash 2GB) then this is your target USB stick to boot from.
Wait for the files to load from the USB.
When the task sequence launches from the USB stick press F8
to bring up a command prompt. Note: Pressing F8 multiple times launches multiple command prompts.
A Task Sequence Wizard window may appear. Simply move this window to
the side of the screen as you are only interested in bringing up a
command prompt.
It is necessary to identify the label volume for the external USB key.
To do this do the following inside the command prompt:
type: Diskpart
Then type: List Volume
You will see a number of volumes listed.
Look for the volume of type removable (as you should only have one removable USB connected to the machine at this time) and
note its label e.g. D
Press F8 again to bring up another command prompt window.
You will now attempt to copy the log file with the following command:
xcopy [source] [destination]
E.g. Type: xcopy X:\windows\temp\SMSTSLog*.* D:\
Source is: X:\windows\temp\SMSTSLog*.*
Destination is: D:\
Then simply remove the USB stick and open in another machine to view SMSTSLog with your editor of choice.
Related
The GPS hardware I'm using with my Raspberry Pi, if sent the command $CDCMD,33,1*7C, will report the status of the antenna connection.
I'd like this command to be issued whenever my GPS daemon starts. My current config file at /etc/default/gpsd looks like this:
# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="/dev/serial0 /dev/pps0"
# Other options you want to pass to gpsd
GPSD_OPTIONS="-n"
# Automatically hot add/remove USB GPS devices via gpsdctl
USBAUTO="false"
# Start the gpsd daemon automatically at boot time
START_DAEMON="true"
Is there anything I can add to this config file to insert either the antenna command, or the path of a file containing the command?
I've searched all over for documentation for the config file, yet all I can find is example file, nothing that fully documents what options are available for configuration.
Alternatively, if the gpsd daemon is already up and running, and already has control of the serial port used to communicate with the GPS hardware, is there a way to send an NMEA command that gpsd will pass along to the hardware?
The only way I've been able to test this command was to shut down gpsd, then run minicom to issue the command to the hardware directly.
I have an UEFI program that requires additional files from the same medium it was started from. This works fine when booting from disk or USB; I can get the device path for the program itself by requesting the EFI_DEVICE_PATH_PROTOCOL (as EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL) from the handle passed to efi_main, and then I modify the path element at the end to find the other files.
When loading via PXE however, the device path I get only contains the path to the Ethernet adapter and the IP protocol:
PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/MAC(...,0x1)/IPv4(0.0.0.0)
The handle only has EFI_LOADED_IMAGE_PROTOCOL and EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL attached, and the FilePath member of the former is an empty path.
Do I still have an IP configuration at this point, or has this been discarded?
Can I find out where the current executable was loaded from?
Can I otherwise express "relative to the current executable"?
In principle I could also repeat the PXE boot, but the PXE menu might contain multiple TFTP servers for different OS installations, so
Can I recover the "active" PXE menu entry?
When I have a bootable USB drive inserted, my UEFI shell places that drive at the FS0 position. As a result, my hard drive, which has the startup.nsh on the boot partition (labeled efidir, not boot), is placed at fs4. The shell can't boot from the startup.nsh, because the efidir partition isn't mounted. When I don't have the USB drive in place, everything works (the hard drive is at FS0, startup.nsh runs, the system boots. To run the startup with a USB in place, I have to switch to FS4 and then run startup from the command line.
Is there a way for me to force the shell to place the hard drive at the FS0 location on the map, regardless of the existence of the USB drive?
My Parallels VM is configured to use some network services on the host mac via the virtual network, but as the virtual network is not up when the mac host's services are started at boot they aren't listening on the virtual interface and the VM can't connect to them. After starting the VM I have to remember to manually restart those services on the mac host so that they are listening on the virtual network. It's annoying when I forget to do so...
I'd like to automate this process if possible. Is there any way to configure Parallels to run a shell script on the host after a VM is started and the virtual network is up? (Suggestions for how to run a startup script on the guest VM are not germane.)
You can prepare script using Automator. Script must be a type "Application". For your purposes, the "Run Sell Script" action is probably the best suited, but you may need something else. After the script is prepared and debugged, you need to move the .app bundle of this script needs to /Applications
Then check in the VM configuration that Options / Aplications / Share Mac applications with Windows are enabled.
Start the VM (or restart it if it's running).
Please find the element with the scipt name at the Parallels Shared Applications folder in Windows Start menu.
Then please right click on it, choose More / Open file location.
Try to launch script by double-clicking on it.
If the "allow open applications" dilog box is appeared, please select "Always Allow".
Press Cmd+R, type "shell:startup", then press OK and copy the element with the script name from the previously opened window to the new appeared window.
That's it.
Now, every VM startup, a script will be launched on the host.
With TestComplete 8 we have a script that is scheduled to start 06:00 every morning by this line:
"C:\Program Files\Automated QA\TestComplete 8\Bin\TestComplete.exe" "C:\Attracs\TestComplete\Attracs\AttracsTEST\AttracsTESTProject.mds" /r /e /SilentMode
The problem is that this often fails. The log remark says:
An error occurred while calling the "Keys" method or property of the "TcxCustomInnerTextEdit" object.
The object or one of its parent objects does not exist.
If I connect to the computer with Remote Desktop and manually run the script it works fine.
There is no screensaver active and the power scheme is set to never sleep.
I have noticed that Testcomplete needs a handle to GUI (the screen is visible) or the script got this kind of errors. Could it be that when it starts it have no handle to the GUI components because they aren't visible ?
From the helps Running Tests via Remote desktop:
However, if you minimize the Remote Desktop window (the window that display the remote computer’s desktop), the operating system switches the remote session to the GUI-less mode and does not display windows and controls. As a result, TestComplete (or TestExecute) is unable to interact with the tested application’s GUI, as the GUI does not actually exist in this case and your automated GUI test fails.
To avoid this issue, you can keep the Remote Desktop window visible during the test run, but this may be inconvenient as it occupies some part or even your entire screen and leaves less space for you to run your local applications.
Any solution for this?
There is a way to enable the console connection in Windows to be active at all times, which allows TestComplete to work without actually connecting with RDP.
From: Running Tests in Minimized Remote Desktop Windows
Log in to the computer from which you
connect to remote computers.
Close all open Remote Desktop
sessions.
Launch the Registry editor
(Regedit.exe).
If you have a 32-bit operating system:
Locate the
HKEY_CURRENT_USER\Software\Microsoft\Terminal
Server Client\ Registry key if you
want to change the connection settings
for the current user only.
-- or --
Locate the
HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal
Server Client\ Registry key if you
want to change the connection settings
for all the users.
Create a new DWORD value in this key
and name it
RemoteDesktop_SuppressWhenMinimized.
Specify 2 as the value data.
If you have a 64-bit operating system:
Locate the
HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Terminal
Server Client\ Registry key if you
want to change the connection settings
for the current user only.
-- or --
Locate the
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Terminal
Server Client\ Registry key if you
want to change the connection settings
for all the users.
Add the
RemoteDesktop_SuppressWhenMinimized
value to the key.
I found this page
http://www.automatedqa.com/support/viewarticle/12567/viewarticle.aspx?aid=12567
It seems that a solution could be that running TestComplete in a Virtual machine.
/Roland
To run any UI test, the UI needs to be available. Hence, the machine should be unlocked so that TestComplete can perform user actions like mouse click, keys, etc to work.
However, if you have non UI test like running Web Services then it will work.