locked
Issue with Posready 2009 fbreseal RRS feed

  • Question

  • I have a problem resealing my Posready2009 basic image. I do a clean install of the Posready 2009 and do the customizations needed for our applications. I copied the fbreseal.exe, setupcn.exe and setupcl.exe from the installation cd to the %systemroot%\system32 of my installation. Then I run the fbreseal.exe command from the command prompt (I tried to run fbreseal with all possible options). After this I shutdown the machine and restart it in WinPE and make an image.

    The problem is when I restore the image (or even when I just restart the machine to see if the resealing was succesfull) after I see the messages windows prepares to start and the fbreseal window with the message resealing, when I log on with the Administrator account created in the initial setup, I see there is a new profile created administrator.computername. It seems like the administrator user does not have the proper rights to access the originial c:\documents and settings\administrator folder. Another strange thing I saw, was that when I looked in the user-groups in the administrators I saw an SID instead of the Administrator user.

    The only work around I found was when I restarted the machine after restoring the image (or after the reseal), was when I saw the log in windows not to login, but to reboot and then to log in. I have seen on some other forums people having the same problem with the same "solution".

    The problem for us is that we want to autologon with the administrator account after restoring the image and running a script to do further OS customizations for our customers. This issue is preventing us to work the way we used to work before. Is there anyone who had the same issue and has a decent solution for this problem? Or ... is there a possibility to make the operating system reboot automatically without logging on (at the point where you boot from the restored image and all the resealing tasks have been finished)?

    I spended already a lot of time to find a solution to this, but at this moment, without success. Is this a bug in the fbreseal program or am I missing something?

     

    Friday, February 4, 2011 8:16 AM

Answers

  • Serge,

    I apologize for my slow response.  It took a while to isolate this issue while carrying on with my formal duties.  I was in the final stages of wrapping up this research just this morning when Adam (engineer working on your support incident) contacted me to inquire about the issue.  I have shared with him the details and he will be getting back to you as well the first of the week.  If you have any questions on the instructions below, he should be able to assist you.

    This issue is caused by the absense of Terminal Services from your POSReady runtime.  For some reason, Windows Embedded requires the Remote Desktop binaries to prevent the creation of the additional accounts.  Adding Terminal Services optional component prior to running FBRESEAL will prevent the additional accounts from being generated.

    If you don't want Terminal Services in your runtime, its removal can be automated using the SYSOCMGR.EXE command line as below. 

    To automate the removal of Terminal Services:

    1.  Create a TXT file with the following contents:

         [Components]
         WOCTSvc=off

          Save this answerfile to your hard drive, noting the location and name of the TXT file.

    2.  Run the Registry Editor and add the following string to
         HKLM\Software\Microsoft\Windows\CurrentVersion\Runonce

         !RemoveTS

         Set the value of !RemoveTS to:  Sysocmgr.exe /i:sysoc.inf /u:(path to your answer file)

    Note: if you want to remove other components using a script like this, you can discover the component names by viewing SYSOC.INF inside the \Windows\INF folder.  Additional information on the use of SYSOCMGR can be found in KB222444, just note that the names of the optional components in POSReady are different from Windows XP.

    4.  Now run FBReseal -Keepall (or other parameters of your choice)

    When the system boots up the first time after FBReseal it will automatically remove Terminal Services.

    Best wishes

    Terry Warwick
    Microsoft


    Terry Warwick Microsoft
    Friday, February 18, 2011 4:33 PM
  • Hi,

    thank you for looking into this. I ve got another solution from your colleague Adam Wicher. He suggested to add the following registry key before doing the fbreseal. I tested this and it worked fine for me.

    [HKEY_LOCAL_MACHINE\System\ControlSet001\Control\Terminal Server]

          "IdleWinStationPoolCount"=dword:00000000

    thanks again for your support.

     

    Friday, February 25, 2011 2:00 PM

All replies

  • Serge,

    I have reproduced the problem that you have encountered and we are researching to see if there are any known workarounds.  Please give me a couple days to see what I can find.

    Terry Warwick
    Microsoft


    Terry Warwick Microsoft
    Thursday, February 10, 2011 1:14 AM
  • Serge,

    I apologize for my slow response.  It took a while to isolate this issue while carrying on with my formal duties.  I was in the final stages of wrapping up this research just this morning when Adam (engineer working on your support incident) contacted me to inquire about the issue.  I have shared with him the details and he will be getting back to you as well the first of the week.  If you have any questions on the instructions below, he should be able to assist you.

    This issue is caused by the absense of Terminal Services from your POSReady runtime.  For some reason, Windows Embedded requires the Remote Desktop binaries to prevent the creation of the additional accounts.  Adding Terminal Services optional component prior to running FBRESEAL will prevent the additional accounts from being generated.

    If you don't want Terminal Services in your runtime, its removal can be automated using the SYSOCMGR.EXE command line as below. 

    To automate the removal of Terminal Services:

    1.  Create a TXT file with the following contents:

         [Components]
         WOCTSvc=off

          Save this answerfile to your hard drive, noting the location and name of the TXT file.

    2.  Run the Registry Editor and add the following string to
         HKLM\Software\Microsoft\Windows\CurrentVersion\Runonce

         !RemoveTS

         Set the value of !RemoveTS to:  Sysocmgr.exe /i:sysoc.inf /u:(path to your answer file)

    Note: if you want to remove other components using a script like this, you can discover the component names by viewing SYSOC.INF inside the \Windows\INF folder.  Additional information on the use of SYSOCMGR can be found in KB222444, just note that the names of the optional components in POSReady are different from Windows XP.

    4.  Now run FBReseal -Keepall (or other parameters of your choice)

    When the system boots up the first time after FBReseal it will automatically remove Terminal Services.

    Best wishes

    Terry Warwick
    Microsoft


    Terry Warwick Microsoft
    Friday, February 18, 2011 4:33 PM
  • Hi,

    thank you for looking into this. I ve got another solution from your colleague Adam Wicher. He suggested to add the following registry key before doing the fbreseal. I tested this and it worked fine for me.

    [HKEY_LOCAL_MACHINE\System\ControlSet001\Control\Terminal Server]

          "IdleWinStationPoolCount"=dword:00000000

    thanks again for your support.

     

    Friday, February 25, 2011 2:00 PM
  • Thank you Serge,

    Adam and I had spoken about this registry key and since he was working with you directly, I did not post the information here to the forum.  I am glad that you were able to resolve the issue with the information that we were able to provide.

    Terry Warwick
    Microsoft


    Terry Warwick Microsoft
    Friday, February 25, 2011 2:44 PM
  • I have this same issue, uh sort of, but I *do* have terminal services installed in my image, which is just xp embedded standard, not POS.  The issue that I'm seeing is the same upon initial booting, where it logs in (I have autologin enabled), but creates a new user.machinename as Serge reported, and is logged in under that user.  If I reboot, then it logs in under the correct name and all is well.  However, I didn't used to have to do the additional reboot.  

    After implementing the registry fix, it worked perfectly!  

    Thanks guys!!

    Steve Letsom

    Rosen Aviation

    Thursday, February 16, 2012 9:16 PM