Where are the user account icons/pictures stored in Windows XP?
(The ones that are displayed on the non-classic logon screen and the start menu.)
C:\Document and Settings\All Users\Application Data\Microsoft\User
Account Pictures\
c:\Windows\system32\msgina.dll, winlogon.exe and logonui.exe contain these resources as bitmaps.
reshack can be used to look at them and if you are adventurous modify them.
You will need to first rename msgina.dll and logonui.exe to something like msgina.old, and then copy in the modified files.
Related
everyone. Sorry if this is difficult to understand, but I accidentally deleted a user profile/account in Active Directory (AD) in Windows Server 2012 R2. I successfully restored the user profile/account to its original state, which was confirmed by the user (They were able to access their previous files and software, while they could not before the restore). The only problem is that their email is having issues. We use Outlook 2016 and Exchange Server 2013. I need to restore the original mailbox to the original Active Directory user. After I restored the original user profile/account, they now have a new mailbox that is empty. They need their original mailbox with their old emails in it and any archived emails for that mailbox. I have found numerous cmdlets to use in PowerShell, but I don’t want to cause any unintentional data loss.
I believe I have found the original mailbox using PowerShell to list any deleted/disabled mailboxes that haven’t been purged after 30 days, and the proper attributes are there (the original shows “Disabled” while the new and empty one has a blank attribute. However, I would love some assistance in this to ensure a successful restoration of the original Active Directory user and their Outlook 2016 mailbox. Can anyone out there please offer some tips or advice? Thank you so much in advance, and I know pictures would help, but I don’t want to post anything unnecessary.
Have a look here:
https://learn.microsoft.com/en-us/exchange/recipients-in-exchange-online/delete-or-restore-mailboxes
Provided you have the appropriate Exchange permissions, you’ll be fine.
Hello and thank you for helping!
I created an Access form that has a few button on it that when clicked format a textbox below the buttons (basically different colors). The idea is for employees to not lose track of important issues to discuss while they are on a phone call with clients. I know Access is typically for database-ing if you will, but I don't need it to track anything or update records as there are none.
This works fine on my computer, however when I try to send it via email or put it on a shared drive, the form appears, but the buttons do not work. I even tried copying the database file along with it to the shared drive, but it still did not work. It seems the VBA code that is connected to the button clicks does not work on a shared drive.
The drive itself is mapped to a letter (Y) on my computer, but may be mapped to Z or another letter on employee computers. Would this be the issue? Or better yet, is there a way to isolate the form so it works like a standalone program on each new machine using it?
I am relatively new to Access, what am I missing?
TL;DR Press button on Access form, textbox turns blue. Send to friends, they try to do the same, nothing happens.
As always, thank you for your time!
EDIT: There are two scenarios that can happen when another user tries to access this form:
1) The form appears perfectly, but when they click the buttons, nothing happens, no text box is formatted.
or
2) It throws this error: 'blah blah drive X' is not a valid path. Make sure that the path name is spelled correctly and that you are connected to the server on which the file resides.
Try the UNC (Universal Naming Convention) instead of the drive letter (Y:)
The format is below.
\servername\sharename\path\filename
The servername and sharename information can be found on "My Computer" for Windows
Finally, this was solved! I changed the Form Record source to be the linked table, and it worked. It was still referencing a table on the computer I created it on. Thank you to everyone who helped!
Here's the situation. I'm am completely new to PowerShell so use small words...
I have a new user in Active Directory that I need to add to about 100 computers as efficiently as possible. My hope was that I could make a PowerShell script that would add the user either through a login script or remotely. I need to have a bit of precision control over this deployment because we don't want to push this user to every computer in the company.
Can PowerShell help me with this, and if not do you all have some sage advice that could help?
To add a user to the local administrators group using PowerShell:
([ADSI]"WinNT://./Administrators,group").Add("WinNT://your-domain/new-user,user")
Just replace the your-domain and new-user parts of the command with the appropriate values for your environment.
Looking for some help here. I do a bit of IT support for an organisation of about 200 people. Most of them use a database program called Filemaker Pro 11. Each user should have their own username that is set under the 'edit' menu -> 'preferences'. The edit menu is on the tool bar at the top of the screen, along with file, view, window etc. like as in MS Word for example.
Each user currently has a default username but the organisation wants everyone changed to a unique username. This means me visiting every machine and manually changing it. I was wondering if it would be possible to write a script to prompt users to make this change the next time they open the system? I'm not new to programming but I've never made a script like this before so wouldn't know where to start. Could anyone point me in the right direction?
There is no way to script that change.
The user name you are referring to is the system (Windows or Mac) user name, and not the FileMaker user account. The default for the system user name is whatever they are logged in to their computer as. So, you could give people unique user names at the system level.
The option that is not default allows the user to change their system name. You can create a script that will open preferences for them, but there is no way to actually change it via a FileMaker script.
What you can do: Use the FileMaker account name instead of system name. The account name is much more reliable, follows the user across computers, is more secure, and best of all is (almost) totally scriptable.
I hope this helps. Sorry that what you want isn't possible inside of FileMaker.
If I find (or create) a new PowerShell cmdlet (or function), how do I add it to my machine?
Do I copy it to a particular folder?
Do I put its content in a particular file?
Do I need to authorize it, or sign it, or give it permission in some way?
I don't want to use it in just one session; I want it to be available whenever I use PowerShell on this machine.
As Alex mentions, any function defined in your profile or in a script that gets "dotted" into your profile will always be available. The same goes if you use Add-PSSnapin in your profile to add a snapin. The cmdlets in the snapin will always be available. For more information about profiles check out the help topic:
man about_profiles
However if you have a significant number of functions you may not want to load them until they are needed. In this case, you can organize functionality into scripts and then put those scripts into one or more directories that are in your path. You can then reference the script by name without specifying the full path or even the .PS1 extension. For more information about using scripts check out the help topic:
man about_scripts
PowerShell V2 introduces an even better approach to organizing functions and loading them on demand. The feature is called Modules and allows you to Import-Module by a simple name (rather than path) and to choose which functions and variable are made public versus which ones remain private. If you have V2, check out modules:
man about_modules
You should access the cmdlets through your profile script. That way, every time you access PowerShell, it gets loaded. See The Power of Profiles.