User Account Picture in start menu is empty if te workstation is part of a domain RRS feed

  • Question

  • Our Vista workstations are part of a domain.

    The user account picture is forced to the default picture using machine policy setting 'Apply the default user logon picture to all users'.


    We also replaced user.bmp with a company-logo, using the same size as the original picture.


    The company logo is shown at the original logon-screen, when unlocking a workstation after a lock, and when user-switching is used.


    However, the picture at the top-right part of the start menu does not show any picture. It shows the picture-frame, but this frame is empty. The area inside the frame is transparent if Aero is enabled.

    There is also an empty frame if there is no user selected. Since the logo should be the same for every user, this should also not be the case; the company logo should be shown.


    Does anyone know how to show the company-logo in stead of an empty frame?

    Or how to remove the empty frame?


    Thanks in advance!





    The discription of the the default user logon picture to all users' policy: This policy setting allows an administrator to standardize the logon pictures for all users on a system to the default user picture. One application for this policy setting is to standardize the logon pictures to a company logo.

    Friday, October 5, 2007 9:57 AM

All replies


    We posted a call @ Microsoft;

    they're working on it...

    Monday, October 15, 2007 9:51 AM
  • We are experiencing the same issue.  Please post the outcome of your conversation with MS on this. Thanks!

    Tuesday, October 16, 2007 4:54 PM
  • I have the exact same issue.  Please post the fix for this when you find it.


    Friday, October 19, 2007 1:36 PM
  • I do not have an answer yet, but happy to know that we're not alone...


    I will post the answer as soon as it is available and tested.


    Update, november 2nd: Still waiting...



    Tuesday, October 23, 2007 11:55 AM
  • The only way to get that to work that I was able to figure out is to delete the other pictures in the following directory.


    %ProgramData%\Microsoft\User Account Pictures\Default Pictures\


    I also placed a copy of the user.bmp in that directory as well as the one in the user account pictures folder.


    If you are using group policy to set that as the logon picture for everyone, just set that policy to not configured. Because there is no other picture for the system to select it will automatically force your company logo to be the only picture available to them. In the GP you can set the control panel to not display user accounts. This will prevent regular users the ability to browse to a picture so they can change their logon picture.


    Oh, does anyone know where the smart card logon picture that is displayed on the logon screen when using a smart card is located? I would like to replace that one with the company logo myself.


    Wednesday, November 7, 2007 2:18 PM
  • Thanks for your answer. That is a working workaround, but is does not prevent users from changing the picture using 'other methods', if any.


    Meanwhile someone at Microsoft is still working on a solution. I seems to be a difficult one, the case is running for over a month now.


    Tuesday, November 13, 2007 8:32 AM
  • Davey400,


    Did you hear anything back from MSFT yet on this? Reason I ask is that SP1 RC has definitely recreated this problem and eliminated a way for anyone to change the picture let alone see a picture in the start menu. I placed another thread on this issue as it relates to SP1.

    I was curious to see if you got any response yet being it has been 2 months now.




    Wednesday, January 9, 2008 7:22 PM
  • Does anyone yet know how to solve this problem with GPO?  This has been going on for about 1 1/2 years, far too long for a stupid picture!!!  This should have been solved in a manner of days.


    Did Microsoft say anything yet?

    Thursday, April 10, 2008 7:16 PM

    Has anyone found an answer to this problem yet?





    Tuesday, April 22, 2008 4:03 PM
  • Not to my knowledge and its pathetic that Microsoft has not responded to this post for an issue that has existed for this long.  This should be an extremely easy issue to solve! 


    The use of the flower picture or other canned Vista pictures is not very representative of a professional organization (unless I'm a floral distributor).  If we're going to associate pictures with accounts, allow us to use something more representative.

    Tuesday, April 22, 2008 4:16 PM

    thats workaround seems not to be working with sp1.

    Any news? I have the exaclty same problem...

    Friday, May 30, 2008 6:16 AM
  • Did you find a solution to this issue?
    Monday, September 22, 2008 8:07 PM
  • I haven't heard anything...still broke.
    Monday, September 22, 2008 8:37 PM
  • I guess if Microsoft can't give a solution to a what seems to be a trivial problem, how can I expect them to solve my more complicated Vista-only problems?  That's the reason I have several open Vista-only cases that have yet to be solved.


    Maybe they should use this testimony on their advertisements.


    Tuesday, September 23, 2008 1:07 PM
  • Maybe you should switch from Vista to "Mojave," people seem to LOVE that version of Windows.
    Tuesday, September 23, 2008 1:28 PM
  • I asked an MS PPS engineer about this issue whilst he was working on something else for me - I am sure he won't mind me posting the response:


    "Regarding the policy “Apply the default user logon picture to all users” this has been accepted as a bug and the Dev team are working on a fix for the same. The occurs because of the following behavior, when a user changes his default picture it writes the bitmap to a .dat file in the user account pictures directory under the name {domain}+{username}.dat. When explorer starts it checks whether this file exists for the logged on user and, if it does, copies the bitmap part of the file into memory. If it doesn’t find it or the policy “Apply the default user logon picture to all users” is applied, it will use the user.bmp or guest.bmp (depending on the user) that are also in the same directory. Its where these files are copied into memory that the problem occurs. We do a check on whether the policy is applied and if it isn’t we’ll copy the bitmap into memory. If it is applied we don’t copy anything into memory and this is why we get a empty frame.


    There was a hotfix request raised for the issue, but this was rejected as this needed changes to shell32.dll a very large and important module for Explorer. The dev guys are working on providing a workaround for the same."

    So the reason this seems to be dragging on without a fix is because the fix requires a major update the a major DLL - which understandably isn't worth the risk just to fix a "cosmetic" issue.

    Tuesday, October 28, 2008 8:30 PM
  • Are there any updates to this issue?
    Friday, July 3, 2009 7:44 AM
  • Hi All, not sure if anyone follows this thread anymore, but I have had to automate the replacement of the default user.bmp file for a client in Windows 7. This is how i did it.

    Firstly I created an msi which simply delivers the clients user.bmp to C:\Windows\Temp\Branding.

    Then using Installshield/Adminstudio (you can do this in any version) I created a custom action to run a vbscript at the "AfterInstallFinalize" part of the execution sequence. The script simply copies the file which the msi delivered (the clients new user.bmp) from C:\Windows\Temp\Branding


    C:\ProgramData\Microsoft\User Account Pictures\

    This is the script I used (embedded in the custom action for those who are interested in that sort of thing)


    on error resume next

    dim filesys
    Set filesys = CreateObject("Scripting.FileSystemObject")

    If filesys.FileExists("C:\ProgramData\Microsoft\User Account Pictures\user.bmp") Then
       filesys.DeleteFile "C:\ProgramData\Microsoft\User Account Pictures\user.bmp"

    End If

    filesys.CopyFile "C:\Windows\Temp\Branding\user.bmp", "C:\ProgramData\Microsoft\User Account Pictures\user.bmp", vbTrue


    I tested the finalised MSI by installing CMDASUSER, a tool to test installs from the LocalSystem account (as this is what Deployemt systems generally use SCCM, ITCM DSM etc, which I've posted here:


    Install it as any user with admin rights and depending on which o/s you are running (32bit or 64bit), will depend on where the program will end up. For x64 - C:\Windows\SysWOW64\cmdasuser.exe, For x32 - C:\Windows\System32\cmdasuser.exe

    To test as Localsystem, in the run box, or from a command shell window, type the path to the cmdasuser .exe and then localsystem..

    So: C:\Windows\System32\cmdasuser localsystem

    There will be a pop up on the taskbar which you can accept to go into a shell under the localsystem context which will present you with a cmd window also running under the localsystem context.

    From here you can just run a test install of the msi : msiexec.exe /I "Pathtoyourmsi" /qb

    Then flip back out of the localsystem shell and check your C:\ProgramData\Microsoft\User Account Pictures dir.

    If all has gone well, you should have a new user.bmp for Windows to use as the default account picture.

    Now all that's left is to distribute it and test through your deployment mechanism.


    Using this package to apply additional branding to Windows 7:

    I've used this package to also deliver branding files to replace default ones or add new jpgs which can then be controlled by Group Policy on specific OUs depending on what you want to control on the o/s, in terms of unified user experience.

    Also this allows for what I think is a really solid method for making sure your Desktop Support / Field Engineers / Service Desk staff put new PCs/Notebooks into the correct OU. If they don't the embarassment is theirs. I guarantee they will only forget to move the PC object once or twice. Imagine having a reasonably clean AD in terms of valid PC object data..I know, its a dream. But this can help...

    C:\Windows\System32\OObe\Info\Backgrounds\backgroundDefault.jpg (The Windows login screen image)

    C:\Windows\System32\Branding (an additional folder)\GenericBackground.jpg


    The GenericBackground and the WrongOU jpgs are fundamental to the training of Desktop Engineers etc.

    Basically, you install the package to deliver the jpgs and then set group policy on the root of the PCs/Notebooks OU which defines the WrongOU.jpg as the default desktop background image.


    Trust me when I say this is an appalling image to have as a forced desktop image and that object will be put in the proper OU quickly.

    The trick is to have the correct OU (a subOU of the root PC/Notebook OU) to NOT have the above policy propogate down but have it's own default desktop image policy pointing at the more "easy on the eye" desktop image.

    So, simply by the desktop image, you know if the PC has been left in a staging OU (where the machine joining the domain for the first time has been created in AD) or has actually been moved at all.

    I haven't got the time to go into the GPO stuff here, but if you have 1 hour and access to the infrastructure to create and deploy (if needed) its an hour worth spent and will get some brownie points for innovation (perhaps). You can claim it as yours guilt free, Zen says it's not really here anyway, so fill your boots :)



    Wednesday, October 13, 2010 4:12 AM
  • wow franks, can i have a copy of that MSI?  I am in the middle of deployment of 108 boxes and realized my refrence capture still has the lil cutsie flower as the default user.bmp was going to have a Gpo to push an script to replace it and it failed several times.  (probably syntax)

    Id rather have it run in the applications sequence in MDT while deploying images.






    Saturday, February 19, 2011 5:59 AM
  • I fixed this by adding a line to the user login script:

    xcopy /y \\Server\Usr\user.bmp "C:\ProgramData\Microsoft\User Account Pictures\user.bmp"

    If you use VB for login scripts, a simple edit of Franks script will do the same.

    I decided against GPO for this due to the bug noted above.
    Thursday, November 17, 2011 5:58 PM