Recovery Media from hell
Here we go again. When I try to save the changes in startnet.cmd it comes back saying access denied.
What method are you using to edit the startnet.cmd file? As a suggestion, it's easiest to do this with Notepad, which is part of WinPE. If you are at a command prompt and have navigated to X:\windows\system32 you should be able to type:
Notepad startnet.cmd
and then edit the file in notepad. When you try to save the file, if you get an "access denied" message, then exit notepad and view the attributes of the startnet.cmd file by typing:
attrib startnet.cmd
Let us know which attributes, if any, have been set on the file. In my highly-customized WinPE, only the Archive attribute is set, so the output of the command looks like this:
X:\windows\system32>attrib startnet.cmd
A X:\windows\system32\startnet.cmd
which shows only that the archive bit (A) is set. You might see (H) for hidden or (S) for system or (R) for read-only. Let us know what you see.
OK,
First step is to make sure there are no type-o's, extra/missing spaces, or extra quotes anywhere at all (don't forget there is a space after the : and the first " too). If you copy and paste the command, make sure to only copy to the end of your set password... there could be an extra space at the end that you're not seeing if you drag beyond it when copying and that will be trying to add that space to your password if this has happened.
As a test, after waiting a few seconds and while your at the command prompt in the WinPE, press the up arrow (it will put the last line typed in) and press enter again to see if it still gives you access denied or not. If it does, the press up arrow again and then the backspace key to delete the last item and press enter again. Does it take then, or still an error? As long as the command is correct all the way through, it should take.
My other thought is that perhaps the NIC hasn't finished spinning up when this is all automated, so we might want to add a delay before the startnet command runs. I've read others having similar delay issues with their NIC and this has helped them. 10 seconds might be long, but would be good to start with and then you could try to take it down to 5 seconds if it works and you don't want to wait the full 10 seconds. Ultimately though, if the password is wrong or the context of the command is off, it won't matter
timeout /t 10
net use s: "\\192.168.0.xx\home\acronis" /user:satwar PASSWORD
(dont' forget the single space between s: and ")
This is a permissions problem. Startnet.cmd is owned by Administrators and Administrators have full permissions. You can edit the file with notepad as long as you run notepad as administrator. You will need to change notepad from txt files to All Files in order for it to see startnet.cmd.
Disregard my note above, but i'll leave it for others. I misread, i thought you were getting access denied to the NAS in WinPE still.
* For your actual issue, another easy way to force the change is save the file to the desktop first. Then copy it back to the mounted folder and when prompted by UAC, allow it. This will get past the permission issue withotu having to do anyting else.
Paul:
How do you run as administrator in WinPE? I thought that WinPE already ran with full permissions.
Edit:
Never mind. Satwar is probably editing the mounted WinPE environment in DISM in Windows 10. Missed that.
Mark,
When WinPE is booted it runs at the System level with full permissions. The problem here is that when you mount the boot.wim file in Windows, you are running at User level. When the Acronis WinPE is mounted in Windows, startnet.cmd is owned by Administrators and Users only have read execute permissions. You can edit it directly by changing ownership to Users and editing the Users permission to give them full rights. It is just easier to edit it with notepad run as administrator because Administrators already have full permissions.
EDIT:
Sorry Mark we posted at the same time.
OK,
My other thought is that perhaps the NIC hasn't finished spinning up when this is all automated, so we might want to add a delay before the startnet command runs. I've read others having similar delay issues with their NIC and this has helped them. 10 seconds might be long, but would be good to start with and then you could try to take it down to 5 seconds if it works and you don't want to wait the full 10 seconds. Ultimately though, if the password is wrong or the context of the command is off, it won't matter
timeout /t 10
net use s: "\\192.168.0.xx\home\acronis" /user:satwar PASSWORD(dont' forget the single space between s: and ")
The automation process worked but the timeout command was not recognized.
Yup, sorry about that. Timeout seems to work in full Windows, but not winPE. Sounds like you may not even need to do this though as it appears to be working.
For those that may need to add a delay, just pinging the internal IP LOOPBACK address would have the same effect. I confirmed this does run in WinPE (should have confirmed the last recommednation too.)
ping - n 10 127.0.0.1
net use s: "\\192.168.0.xx\home\acronis" /user:satwar PASSWORD
Yes it works perfectly without the delay.
Thank you so much, again, to everyone.
After that experience I need some rest away from this project, before I try the bare metal restore process again. This whole process of creating a custom winpe was to achieve a recovery without requiring any fixing of Windows Boot Manager in the bios boot sequence of my Dell XPS 15 (9550) laptop, when I booted from the simple linux bootable media. We have yet to see if it gives better results.
Call me gun shy, but Acronis keeps sending a message "You have selected a remote resource and have not specified credentials. Do you want to continue ?" every time I try to select a backup file. I selected the backup file I wanted to recover and then tested Authentication and Acronis said it was okay. But I still get the warning when I select the backup file to recover again.
Should I be concerned, or is it normal procedure to provide credentials and just ignore ?
If the remote resource is your NAS and it's already mapped in Windows as a drive letter or connected in Windows, then Acronis should be able to navigate to it without providing the credentials since Acronis has access to whatever shares/mapped drives are available already in Windows.
It probably depends on how you're connecting to the NAS device in Windows and/or whether that NAS share is open to unauthenticaed users or is password protected. As long as the remote source is your own, I wouldn't worry about it. I've never seen this error/warning myself though.
A thing of beauty, and the Windows Boot Manager is still in place. There were a lot of scary messages with the linux based recovery media, but none with the Custom WinPE recovery media.
Please do me one favor, don't advise people with Dell xps to use linux based recovery and switching Raid to AHCI. There's a lot of scary stuff that's going to happen, and I don't wish it on anyone. Custom WinPE is the only way to fly.
Thank you again for all your help, it's too bad tech support doesn't know more, because they almost lost a sale with me.
If only we could get Acronis to make the WinPE builder more user friendly and include driver injection and NAS connectivity by default! I've been asking for it for quite some time now! I can understand that Microsoft prevents the distribution of WinPE, but it shouldn't limit us from being able to use tools to create the WinPE ourselves with some help from the Acronis application. With so many newer laptops coming prebuilt with NVME PCIE hard drives and/or RAID enabled by default, WinPE is really the only good way to accomodate them correctly at this point in time.
The default Linux method works great for standard AHCI systems, but has always been lacking for systems using RAID as the SATA mode due to non-existent IRST or custom RAID controller drivers in Linux. The AHCI work-a-round does work, but sounds like it may require a system repair to fix the bootloader as a result - not something I've noted in particular myself but will be something that I shall be testing more in the future.
I want to say thanks to you too for hanging in there and working through this. You seem to have some IT experience - more than most home users... and the willingness to keep going to get it resolved is appreciated from this end as well. When others are out of their comfort zone, many just dont' care to keep going as they expect things to work right out of the box.
Technically all is working with WinPE as designed to by Microsoft, but I personally feel that it is necessray to automate the driver injection process and NAS connections so that it is all streamlined for end-users. Heck, the driver injection in the Universal Restore media builder for WinPE is already there, so I'm at a loss as to whey it's not there for the main applictation too. If you feel the same, please let Acronis know too, by submitting the in-app feedback from the Acronis GUI! Also, let them know that if it weren't for the MVP's, this would not have been a happy ending :) I'm just glad it all worked out in the end for you and we've all learned a bit in the process too!
Satwar:
I get that message too and simply ignore it. It isn't necessary to test Authentication; everything will work out if you have a drive map established.
One of the MVPs who chimed in on this thread is Mustang, and he has a custom WinPE builder available that you should check out if you want an even better WinPE recovery environment: https://forum.acronis.com/forum/124947. Now that you've gotten this far, building MustangPE should be easy for you.
There was more than just boot manager problems. During the recovery process with linux media, there were huge yellow warning signs popping up that warned that the system would become unbootable, but I thought that was Acronis being conservative, but it was actually indicating trouble ahead.
................................
The default Linux method works great for standard AHCI systems, but has always been lacking for systems using RAID as the SATA mode due to non-existent IRST or custom RAID controller drivers in Linux. The AHCI work-a-round does work, but sounds like it may require a system repair to fix the bootloader as a result - not something I've noted in particular myself but will be something that I shall be testing more in the future.
..............................