Is there a way to only migrate select local accounts when using the USMT tool.
This is the command I use, but it does all local accounts, not specific ones.
scanstate \workdocs /i:migapp.xml /i:migdocs.xml /i:miguser.xml /o /v:13 /localonly /c /uel:30 /efs:copyraw
From my research the only way would be to limit the scope of users by /uel option.
The /uel switch replaces the /user option from previous version of USMT. It allows you to migrate only users that have logged into the source computer within a specific amount of time. This prevents you from transferring data from users who may have logged into that machine for some reason in the distant path, but most likely do not need their profiles moved.
I would like to plan and test my database recovery in another site (another instance on another server in disaster recovery site).
I take a monthly RMAN level 0 image copy every month and daily incremental level 1 backups.
The database is running in noarchivelog mode. The online redo logs are multiplexed to a disk in the disaster recovery site. Also we have a recovery catalog on another server.
I want to test restoring the recent (yesterday) backup to database in disaster recovery site and then recover to just apply the online redo log files, how to achieve that?
side question: Is it sufficient to recover if we only have a yesterday backup and the online redo logs containing all transactions of today and none of them was overwritten? Since the database is in noarchivelog mode.
What is the use of archivelog mode if we have a daily backup and the redo logs are not overwritten during the day until the backup is taken?
what is the use of backing up archive logs?
You are working with a dangerous setup since you seem to be betting on redo log files that are never filled up between your backups. When your data has no value, go ahead, otherwise switch to archive log mode.
Archives are created when a redo log group fills up. So, in your case you need to copy the online redo log files manually to the remote site for recovery.
How sure are you about the redo log files not being overwritten?
Be sensible and if this is production switch to archive log mode. Otherwise, promise not te make promises about being able to make point in time recoveries.
An other point: if your online redo log files are damaged, your database has a big problem and in your case you might loose a day worth of work. Is that OK? If not, reduce the size of the redo log files to a limit where it does make a switch every now and then. I am sure your company has an idea about how much time they can accept loosing transactions from. Many companies allow less than one hour transaction loss.
IIS 10 will not restart on my PC. When I navigate to localhost, I get a 'localhost refused to connect' message. After looking through the event viewer, it turns out that the issue is that the Windows Process Activation Service (WAS) will not start.
The error message given is:
'The Windows Process Activation Service (WAS) encountered an error while handling key generation. This will prevent WAS from starting corrently. The data field contains the error number.'
When I try to start the service manually from the services app, I get the following:
Has anyone experienced this issue before? Any help would be greatly appreciated, I've been trawling the internet for several days trying to find a solution to no avail.
We've run into this issue several times after recent Windows Updates. In all cases, the following worked (got from a Microsoft support rep):
Run the following from an admin Powershell prompt:
reg delete HKLM\SYSTEM\CurrentControlSet\Services\WAS\Parameters /v GenerateKeys /f
net start w3svc
The keys will be regenerated, then the IIS AppPools can be started
According to your error message, WAS can not access the machine key when start up. Usually, machine keys are used to encrypt sensitive information in config file, WAS will not be able to start if there is no machine key to use.
The easiest and most common method is to try to uninstall and reinstall WAS.
If it still can not start, try to delete the registry entry NanoSet with cmd.
If the above two methods are useless, you can refer to this to delete machine keys, let WAS create new one while starting.
If somebody is still fighting with this issue, please check Event Viewer under System filter and check for any logs related to WAS. In my case I found the following entry:
The Windows Process Activation Service (WAS) encountered an error while handling key generation. This will prevent WAS from starting currently. The data field contains the error number.
So I just started again CNG Key Isolation service and everything is working now.
I am running a Jenkins server on a Windows 10 computer, as a service. In one of the Jenkins-jobs I have to perform tests using a COM application. The same computer is also used by the developers in their daily work over RDP, and the Jenkins-job in question is run in the night when no regular developer is using it. But if no user is logged in on the computer or using RDP, the script in the job fails to start the COM application with the following message:
The server process could not be started because the configured
identity is incorrect. Check the username and password.
I found that the issue seems to be that the identity for the COM application is taken from the current interactive user, and if there is none, it fails, see
https://support.microsoft.com/en-my/help/305761/com-server-application-that-uses-interactive-user-identity-fails-to-lo
I cant seem to be able to solve my issue. I see two options:
Make sure that a user is logged in when the job is executed
Figure out how to run the COM application without an interactive user
For 1 i see the following solutions and why they do not work:
Autologin on Windows start, and leave logged-in: Will not work since we use the computer in our daily work through RDP, which means that the local logged in user will be kicked out since we are only allowed one session at a time.
Log in using RDP and then exit using the script tscon.exe 0 /dest:console which will leave the session open. Will not work since we are 15 people in the team using that machine over RDP, and people will forgett to use this command when they log of by the end of the day.
For 2, i am unable to find a way to do this.
Can I in Windows schedule a user to automaticall be logged in before the job starts? Can i use a second computer and scedule an RDP-session to the first computer, before the job is executed?
Since nobody was able to provide a good solution I will input my workardound as an answer and possible solution. What I ended up doing was using a second computer (running Windows) and schedule a task on that computer that every night (before the Jenkins-job starts) opens an RDP-session to the computer running Jenkins. This way the Jenkins job, and the COM-application, has an active user that it can use.
This is how I achieved this:
Login to the second computer (i.e. the one not running Jenkins) and open the RDP (Remote Desktop Connection) dialog and click Show Options
Enter the details for the first computer (i.e. the one running Jenkins). Make sure to uncheck Always ask for credentials (you will need to save the credentials to be able to automate this).
Save the configuration to an .rdp-file, using Save As...
IMPORTANT: Press connect to connect to the first computer, enter the password and make sure to save it. Also accept any certificates e.t.c. to prevent future warnings/dialogs.
Create a bat-file containing the following
mstsc C:\Path\To\saved_rdp_file.rdp
Create a task in Windows Sceduler that calls the bat-file created in step 5 every night.
Optional: If you want to close the rdp-session when Jenkins is done, create a second bats-script and scedule that as well, containing:
tasklist /FI "imagename eq mstsc.exe" | find "mstsc.exe" && taskkill /f /im mstsc.exe || echo process "mstsc.exe" is not running
Suppose some Windows service uses code that wants mapped network drives and no UNC paths. How can I make the drive mapping available to the service's session when the service is started? Logging in as the service user and creating a persistent mapping will not establish the mapping in the context of the actual service.
Use this at your own risk. (I have tested it on XP and Server 2008 x64 R2)
For this hack you will need SysinternalsSuite by Mark Russinovich:
Step one:
Open an elevated cmd.exe prompt (Run as administrator)
Step two:
Elevate again to root using PSExec.exe:
Navigate to the folder containing SysinternalsSuite and execute the following command
psexec -i -s cmd.exe
you are now inside of a prompt that is nt authority\system and you can prove this by typing whoami. The -i is needed because drive mappings need to interact with the user
Step Three:
Create the persistent mapped drive as the SYSTEM account with the following command
net use z: \\servername\sharedfolder /persistent:yes
It's that easy!
WARNING: You can only remove this mapping the same way you created it, from the SYSTEM account. If you need to remove it, follow steps 1 and 2 but change the command on step 3 to net use z: /delete.
NOTE: The newly created mapped drive will now appear for ALL users of this system but they will see it displayed as "Disconnected Network Drive (Z:)". Do not let the name fool you. It may claim to be disconnected but it will work for everyone. That's how you can tell this hack is not supported by M$.
I found a solution that is similar to the one with psexec but works without additional tools and survives a reboot.
Just add a sheduled task, insert "system" in the "run as" field and point the task to a batch file with the simple command
net use z: \servername\sharedfolder /persistent:yes
Then select "run at system startup" (or similar, I do not have an English version) and you are done.
You'll either need to modify the service, or wrap it inside a helper process: apart from session/drive access issues, persistent drive mappings are only restored on an interactive logon, which services typically don't perform.
The helper process approach can be pretty simple: just create a new service that maps the drive and starts the 'real' service. The only things that are not entirely trivial about this are:
The helper service will need to pass on all appropriate SCM commands (start/stop, etc.) to the real service. If the real service accepts custom SCM commands, remember to pass those on as well (I don't expect a service that considers UNC paths exotic to use such commands, though...)
Things may get a bit tricky credential-wise. If the real service runs under a normal user account, you can run the helper service under that account as well, and all should be OK as long as the account has appropriate access to the network share. If the real service will only work when run as LOCALSYSTEM or somesuch, things get more interesting, as it either won't be able to 'see' the network drive at all, or require some credential juggling to get things to work.
A better way would be to use a symbolic link using mklink.exe. You can just create a link in the file system that any app can use. See http://en.wikipedia.org/wiki/NTFS_symbolic_link.
There is a good answer here:
https://superuser.com/a/651015/299678
I.e. You can use a symbolic link, e.g.
mklink /D C:\myLink \\127.0.0.1\c$
You could us the 'net use' command:
var p = System.Diagnostics.Process.Start("net.exe", "use K: \\\\Server\\path");
var isCompleted = p.WaitForExit(5000);
If that does not work in a service, try the Winapi and PInvoke WNetAddConnection2
Edit: Obviously I misunderstood you - you can not change the sourcecode of the service, right? In that case I would follow the suggestion by mdb, but with a little twist: Create your own service (lets call it mapping service) that maps the drive and add this mapping service to the dependencies for the first (the actual working) service. That way the working service will not start before the mapping service has started (and mapped the drive).
ForcePush,
NOTE: The newly created mapped drive will now appear for ALL users of this system but they will see it displayed as "Disconnected Network Drive (Z:)". Do not let the name fool you. It may claim to be disconnected but it will work for everyone. That's how you can tell this hack is not supported by M$...
It all depends on the share permissions. If you have Everyone in the share permissions, this mapped drive will be accessible by other users. But if you have only some particular user whose credentials you used in your batch script and this batch script was added to the Startup scripts, only System account will have access to that share not even Administrator.
So if you use, for example, a scheduled ntbackuo job, System account must be used in 'Run as'.
If your service's 'Log on as: Local System account' it should work.
What I did, I didn't map any drive letter in my startup script, just used net use \\\server\share ... and used UNC path in my scheduled jobs. Added a logon script (or just add a batch file to the startup folder) with the mapping to the same share with some drive letter: net use Z: \\\... with the same credentials. Now the logged user can see and access that mapped drive. There are 2 connections to the same share. In this case the user doesn't see that annoying "Disconnected network drive ...". But if you really need access to that share by the drive letter not just UNC, map that share with the different drive letters, e.g. Y for System and Z for users.
Found a way to grant Windows Service access to Network Drive.
Take Windows Server 2012 with NFS Disk for example:
Step 1: Write a Batch File to Mount.
Write a batch file, ex: C:\mount_nfs.bat
echo %time% >> c:\mount_nfs_log.txt
net use Z: \\{your ip}\{netdisk folder}\ >> C:\mount_nfs_log.txt 2>&1
Step 2: Mount Disk as NT AUTHORITY/SYSTEM.
Open "Task Scheduler", create a new task:
Run as "SYSTEM", at "System Startup".
Create action: Run "C:\mount_nfs.bat".
After these two simple steps, my Windows ActiveMQ Service run under "Local System" priviledge, perform perfectly without login.
The reason why you are able to access the drive in when you normally run the executable from command prompt is that when u are executing it as normal exe you are running that application in the User account from which you have logged on . And that user has the privileges to access the network. But , when you install the executable as a service , by default if you see in the task manage it runs under 'SYSTEM' account . And you might be knowing that the 'SYSTEM' doesn't have rights to access network resources.
There can be two solutions to this problem.
To map the drive as persistent as already pointed above.
There is one more approach that can be followed. If you open the service manager by typing in the 'services.msc'you can go to your service and in the properties of your service there is a logOn tab where you can specify the account as any other account than 'System' you can either start service from your own logged on user account or through 'Network Service'. When you do this .. the service can access any network component and drive even if they are not persistent also.
To achieve this programmatically you can look into 'CreateService' function at
http://msdn.microsoft.com/en-us/library/ms682450(v=vs.85).aspx and can set the parameter 'lpServiceStartName ' to 'NT AUTHORITY\NetworkService'. This will start your service under 'Network Service' account and then you are done.
You can also try by making the service as interactive by specifying SERVICE_INTERACTIVE_PROCESS in the servicetype parameter flag of your CreateService() function but this will be limited only till XP as Vista and 7 donot support this feature.
Hope the solutions help you.. Let me know if this worked for you .
I find a very simple method: using command "New-SmbGlobalMapping" of powershell, which will mount drive globally:
$User = "usernmae"
$PWord = ConvertTo-SecureString -String "password" -AsPlainText -Force
$creds = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, $PWord
New-SmbGlobalMapping -RemotePath \\192.168.88.11\shares -Credential $creds -LocalPath S:
You wan't to either change the user that the Service runs under from "System" or find a sneaky way to run your mapping as System.
The funny thing is that this is possible by using the "at" command, simply schedule your drive mapping one minute into the future and it will be run under the System account making the drive visible to your service.
I can't comment yet (working on reputation) but created an account just to answer #Tech Jerk #spankmaster79 (nice name lol) and #NMC issues they reported in reply to the "I found a solution that is similar to the one with psexec but works without additional tools and survives a reboot." post #Larry had made.
The solution to this is to just browse to that folder from within the logged in account, ie:
\\servername\share
and let it prompt to login, and enter the same credentials you used for the UNC in psexec. After that it starts working. In my case, I think this is because the server with the service isn't a member of the same domain as the server I'm mapping to. I'm thinking if the UNC and the scheduled task both refer to the IP instead of hostname
\\123.456.789.012\share
it may avoid the problem altogether.
If I ever get enough rep points on here i'll add this as a reply instead.
Instead of relying on a persistent drive, you could set the script to map/unmap the drive each time you use it:
net use Q: \\share.domain.com\share
forfiles /p Q:\myfolder /s /m *.txt /d -0 /c "cmd /c del #path"
net use Q: /delete
This works for me.