locked
Applying Autologin Profile to Windows Embedded Standard 7 Thin Client RRS feed

  • Question

  • I am trying to apply an  Autologin account to a Windows Embedded 7 device that already has the FBWF enabled using a post-operating system deployment task sequence. So, basically I have an OS task sequence that installs the OS, CM and SCEP agents, as well as a couple base applications like Adobe Reader and Flash then enables the FBWF. From there I have this "Autologin Specific" task sequence to apply the specific autologin account as well as a couple applications.

    The "Autologin Specific" task sequence applies the autologin registry keys to set it as an autologin user. The task sequence completes, thus enabling the write filter and the computer boots up and logs in as the autologin user, HOWEVER, after any subsequent reboots a balloon message from the task appears that the user has been logged on with the temporary profile - I believe this is because it can not successfully commit any changes to the protected volume because the FBWB was enabled after the task sequence completed. I am unable to log the user into the computer during the task sequence because CM puts the computer is in Service Mode (where only the local Administrator can log on - because the Write Filter is disabled).

    I have also attempted to run the script to apply the autologin user in the OSD task sequence before enabling the Write Filter for the first time. This does not work because the computer never exits "sysprep" mode and logs the user in before the script to enable the write filter kicks in.

    I do not want my OSD to finish with the Write Filter disabled because if a machine is being imaged at location, there will be a period of time where a user will be able to walk up and log in, before any additional task sequences are run to lock it down.

    HP's answer is to use HPDM or basically use command lines to tun the filter off and on. Uh - Not much help here when CM is putting a computer in Service Mode.

    Any thoughts?

    Friday, December 12, 2014 8:53 PM

Answers

  • Daniel,

    We do not have Orchestrator implemented in our environment, although it has been discussed. But I do need to have some solution in place rather quickly, so even if that was an option soon, it isn't now.

    My resolution:

    Omit enabling the Write Filter until after the computer is delivered by the tech. When a tech delivers a thin client to a location, they will do the following.

    1. Manually change computer name and add printer.
    2. In CM, move computer to collection that:
              A. Has a Required Deployment of a Program (VB script) that is also scheduled to run once a day. The VB Script checks to see if the File-Based Write Filter is enabled. If it is, it closes. If the Filter is not enabled it enables it, along with our exclusions and the BCD Fixit command, then reboots the computer.
              B. The collection also has a Custom Client Setting for Restart. Since CM puts the thin client in Service mode when deploying applications and other tasks, I want the thin clients to reboot as close to immediately after the task is done, so users don't have to wait any longer than necessary. The policy is set for Diplay notification for 2 minutes, and Display dialog box for 1 minute.
              C. The collection also updates it membership just prior to the scheduled time to run the VB script. 


    • Edited by guitarkevin Wednesday, December 17, 2014 10:35 PM
    • Marked as answer by Daniel JiSun Thursday, December 18, 2014 2:05 AM
    Tuesday, December 16, 2014 3:57 PM

All replies

  • Hello,

    The user profile is not written onto the volume, but the user account information is stored in the computer. So this behavior is normal. And it doesn't matter for end users.

    To prevent this, you can enable FBWF after first log on. In this way, there will be a user profile assotiated with your default user account. As suggested from HP, the tool should help.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, December 15, 2014 9:54 AM
  • I've setup a post-OSD task sequence and am testing it now:

    1. Apply autologin account (reg keys)
    2. Restart computer (so profile logs in)
    3. Install account-specific applications
    4. Sleep 20 minutes (Microsoft recommends 15-20 minutes after the OSD so the CM agent properly registers)
    5. Enable FBWF and apply BCD Fixit

    My only other concerns at this point are:

    Installing printers. We don't always know what printer a computer prints to until deployed to location. I would love to have a method that doesn't involve disabling the FBWF, rebooting, installing printer, enable FBWF, rebooting. Too much room for error on the tech to remember to re-enable the FBWF. If they do know the printer to install they can do it during the 20 minute sleep process above.

    Renaming a computer. Our naming scheme is such that we keep the same computer name when we replace a computer (I know, cringe). So I need my desktop techs to be able to do this on site when they deliver a replacement computer. Again, some automated process would be great, like a CM job that prompts for PC name and then takes care of the Write Filter and reboots (I am still testing this as well).

    But I would love to hear any thoughts on these subjects. Thanks

    Monday, December 15, 2014 4:43 PM
  • Hello,

    Do you have orchestrator deployed in your environment? If so, you can do these thing with runbook. Thus nothing will be missed.

    Another solution I think is to create exclusion list, as described in the following article:

    http://msdn.microsoft.com/en-us/library/ee832773.aspx#Add_File


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, December 16, 2014 2:06 AM
  • Daniel,

    We do not have Orchestrator implemented in our environment, although it has been discussed. But I do need to have some solution in place rather quickly, so even if that was an option soon, it isn't now.

    My resolution:

    Omit enabling the Write Filter until after the computer is delivered by the tech. When a tech delivers a thin client to a location, they will do the following.

    1. Manually change computer name and add printer.
    2. In CM, move computer to collection that:
              A. Has a Required Deployment of a Program (VB script) that is also scheduled to run once a day. The VB Script checks to see if the File-Based Write Filter is enabled. If it is, it closes. If the Filter is not enabled it enables it, along with our exclusions and the BCD Fixit command, then reboots the computer.
              B. The collection also has a Custom Client Setting for Restart. Since CM puts the thin client in Service mode when deploying applications and other tasks, I want the thin clients to reboot as close to immediately after the task is done, so users don't have to wait any longer than necessary. The policy is set for Diplay notification for 2 minutes, and Display dialog box for 1 minute.
              C. The collection also updates it membership just prior to the scheduled time to run the VB script. 


    • Edited by guitarkevin Wednesday, December 17, 2014 10:35 PM
    • Marked as answer by Daniel JiSun Thursday, December 18, 2014 2:05 AM
    Tuesday, December 16, 2014 3:57 PM