Every reference to applying a wallpaper to a computer via AD goes through the user.
I need to apply a wallpaper to a set of computers, a student lab specifically, and a wallpaper specific to that lab.
Students have their own AD accounts and due to that I don't have access to their accounts, just these computers.
If you can use Group Policy at the Active Directory level you could specify a wallpaper, the image could either be on the local PC or accessible through a UNC path. Doing it via GPO will mean the wallpaper cannot be changed by the user and you have control over the images.
You can achieve this by opening Group Policy Management and editing a policy to apply the setting to.
The exact path to the object will depend upon the version of GPO you are running, on my PC it is User Configuration > Policies > Administrative Templates > Desktop > Desktop > Desktop Wallpaper.
You would then enable the setting and complete the wallpaper options - Path and style.
You may find this page useful it has some screen shots and a couple different methods to set this through Group Policy: http://www.grouppolicy.biz/2011/03/best-practice-using-group-policy-to-configure-desktop-wallpaper-background/
Related
We are having issues with employees' adobe where the save as will just create a grey box with no options and they are forced to restart their adobe acrobat. The solution is to uncheck the "show online storage when saving files" option. But going to every computer and account and disabling them would be a nightmare. Is there anyway we could implement a script of some sort of script for our active directory to automatically disable this setting?
I am not much of a programmer or scripter so any help is much appreciated. Thanks.
• The registry key path for the option ‘Show online storage when saving files’ is ‘HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\DC\AVGeneral’ and the key for this option is ‘bToggleCustomSaveExperience’ is ‘DWORD’ value which is set when the option in Adobe is checked, i.e., its value is ‘00000000’.
• So, to uncheck it and remove that option from multiple systems, we can use the following script and deploy it through Group policy on all the systems where Adobe is installed.
‘ Set-ItemProperty -Path HKCU:\SOFTWARE\Adobe\Acrobat Reader\DC\AVGeneral -Name bToggleCustomerSaveExperience -Value 00000001 -Type DWord ‘
When you execute the above powershell command on a Windows system with Adobe where the setting needs to be unchecked, it successfully unchecks that option from registry. Also, you need to save the above command in a ‘.ps1’ extension document for it to run successfully and deploy this script through group policy as follows: -
Go to your Domain Controller and open the Group policy management console. Then create or edit a GPO (default domain policy).
Navigate to ‘Computer Configuration\Policies\Windows Settings\Scripts (Startup/Shutdown)’
Select ‘Startup or Shutdown’ as per your convenience, select ‘Powershell Scripts’ then select ‘Add’, then browse to the script location, select the script file, then ‘OK’ and save the configuration.
Also, set the priority of the GPO accordingly and deploy it across the domain.
• When this script is deployed and executed successfully, the said setting is automatically disabled, and your issue is resolved.
Apologies if this is a really simple question...
We have a .NET application that is installed by an administrator, and then run by multiple staff on the same computer with their own login credentials (normal user - non-admin).
Application uses MSI installer and is installed to Program Files folder.
The application needs to have some settings about attached devices to the computer saved as preferences so when a user opens the app these settings are set and the user is not asked for preferences each time. These preferences should not be set per user, rather per computer.
However if user A changes one of these settings on the computer, then when user B logs in they should see the changed setting from user A.
Hence the settings need to be per computer, not per user.
Where in windows 7,8,10 etc. can an application save data that is computer specific not user specific, yet allow users without admin rights to change that data?
We have looked at system temp folder but the computers have GPO policy to regularly remove temp folder content.
Any other ideas?
It takes administrator rights to change the permissions on a registry key inside HKLM, but once that's done, anyone in the group given permission can make modifications.
Obviously don't change permissions on any of the standard keys (e.g. HKLM\Software or HKLM\Classes) but in your own application area (HKLM\Software\YouCorp\YouApp\Attached Devices) it's perfectly fine to adjust permissions the way you like.
You'll just have to include "grant write permission on HKLM\Software\YouCorp\YouApp\Attached Devices to the group Users" as one of the actions of your installer.
If you are allergic to the registry, you can do the same with a subdirectory of your application install (e.g. %ProgramFiles%\YouCorp\YouApp\Device Settings)
Given you are using a .Net application, you could store the information in the app.config file associated with the application.
Assuming I am logged on as administrator, can I use PowerShell to assign a desktop background image to a specific user account?
I've seen answers similar to this one
Powershell script from shortcut to change desktop
where the following is used
RegistryKey key = Registry.CurrentUser.OpenSubKey("Control Panel\\Desktop", true);
Which, I assume, will work for the currently logged on user. How would I do that for the user that is not logged on (any user)?
The user did not have a desktop background set before.
Any other automated solution welcome, not limited to PowerShell.
The general consensus seems to be that you need to load the user's registry hive. I think this is what you're looking for: http://jrich523.wordpress.com/2012/03/06/powershell-loading-and-unloading-registry-hives/
I need to create an NSIS installer, which runs with administrator privileges. I request these privileges with
RequestExecutionLevel admin
So far this works. But I also need to place shortcut links on the users desktop. I do NOT want to create the shortcuts for all users but only for the currently logged in user. So I use
SetShellVarContext current
in the installer sections. If the current user has admin privileges, this works. If I have a normal user, Windows (7) asks for credentials for a privileged user, which is also correct. But the installer then creates the icons on the privileged users desktop, and not on current users.
So, how can I tell NSIS, that it should create desktop icons for the current user if she has no admin privileges?
FYI, if I omit both RequestExecutionLevel and SetShellVarContext, I am also prompted for administrative rights but the installer creates icons on the current user desktop as well as for the admin user. I think this is some kind of compatibility behavior.
You are not really supposed to do this (because of this exact issue) and you are basically asking how to create a installer that is broken by design. This is not a NSIS specific problem and not even UAC specific, it has existed since runas was added in Win2000! When you elevate with runas/UAC the new process is executed as that user and with their HKCU and shell folders...
If you need "RequestExecutionLevel admin" in your script then you are doing machine level things and should therefore call "SetShellVarContext all" and install the files in $ProgramFiles and write the uninstall registration under HKLM. This is true for any version of NT, not just Vista+/UAC. (Most people forget to test as non-admin on NT4 and NT5)
If creating shortcuts for all users is such a big problem then I suggest you enable the "Don't create shortcuts" checkbox on the startmenu page so the user can decide.
If you still want to force broken behavior then you need to use this plugin. (You should be able to find plenty of topics about this plugin on the NSIS forum)
I have a VB6 application which links to several POS terminals from a Windows 7 32-bit machine. The POS terminals are mapped to the Windows 7 machine and I can access the POS terminals from the Windows 7 machine from Explorer or via the cmdline/shell.
The application has been updated to ADO 2.8 and all other controls and components I no longer had source code for have been re-written. After a few annoying hiccups, I got the application to recompile on the Windows 7 computer without errors.
Now come the problems. The VB6 application cannot see or navigate to any mapped drives! I have tried twiddling UAC settings; I have set the app to run in Windows XP SP3 mode; I have tried running as Administrator. None of these things (and many permutations of these) work.
Any suggestions on how to make this work?
Adding this registry setting solved the problem for me: http://technet.microsoft.com/en-us/library/ee844140%28v=ws.10%29.aspx.
To work around this problem, configure the EnableLinkedConnections
registry value. This value enables Windows Vista and Windows 7 to
share network connections between the filtered access token and the
full administrator access token for a member of the Administrators
group. After you configure this registry value, LSA checks whether
there is another access token that is associated with the current user
session if a network resource is mapped to an access token. If LSA
determines that there is a linked access token, it adds the network
share to the linked location. To configure the EnableLinkedConnections
registry value
Click Start, type regedit in the Start programs and files box, and
then press ENTER.
Locate and then right-click the registry subkey HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
Point to New, and then click DWORD Value.
Type EnableLinkedConnections, and then press ENTER.
Right-click EnableLinkedConnections, and then click Modify.
In the Value data box, type 1, and then click OK.
Exit Registry Editor, and then restart the computer.
I believe you are having trouble because casual drive mapping is per-user, and on a UAC system Administrators group users have two separate contexts (one for each token: SU & elevated).
There is such a thing as a system level drive mapping, which is one done under the System user (NT Authority\System). When you map a drive under this account, and map it persistently, all users can see and use the mapping (subject to the usual access rights for files there).
The normal way you do this is via Domain-level GPOs (Group Policy Objects), which means bribing your local box jockeys if in a corporate managed LAN environment.
One way to do this in a Workgroup machine is to map the letter as System via the AT command, from an elevated command prompt:
at 8:53 am "net use m: \\MediaShare\MyLibrary
ThePW /user:MediaShare\TheUser /persistent:yes > nul"
There the remote server is MediaShare, user TheUser, password ThePW, and 8:53 AM is a minute or two in the future to avoid accidentally scheduling this for tomorrow.
But this fails on Vista and later due to Session 0 Isolation!
So... use the 3rd alternative at Run CMD.exe as Local System Account which is the same thing mentioned by ForcePush's reply to How to map a network drive to be used by a service.
I believe that's what you are after here.
don't know if you ever figured this one out but for me it was the ChDir command (even with the registry fix above).
I had in my code
ChDir "P:\Temp\VidCap\Cam1\" 'I almost never use ChDir
Open "list.txt" For Output As #1
and all the VB6 inbuilt file commands looked straight though any operations, no errors, no nothing. I solved it by explicitly having the path, (in my code it was in a string but you could have it explicitly):
dd = "P:\Temp\VidCap\Cam1\"
Open dd & "list.txt" For Output As #1
works as expected.
hope this helps
H
Try this:
Open command prompt as administrator, and type this in:
net use Z: \\IP Address\share /user:you passwd /persistent:Yes
Change "IP Address", the "share" name, and your username and password as needed.
The author of this is howtogeek (source).
I had same problem. VB6 kept crashing when trying to access USB and mapped drives using the Commondialog method, even though the drives and files were all accessible OK via Explorer. Problem is the drives were not set as shared.
Solved by selecting the connected USB drive in explorer and then right click to
select Properties.
Select Sharing Tab
Select Advanced Sharing
Set the sharing and user rights as needed. May need to have local admin rights.