We have migrated our Windows user PCs to new Domain.
For each clearcase user, We need to do below work manually.
1. Albd service account and password to be changed in Service window category.
2. In Registry domain name need to be changed.
3. Old domain snapshot views needs to be find and unregistred.
4. Again same snapshot views need to be registered for New hostname.
5.Fix_Prot needs to be run to change snapshot views owner and group name.
So for this do we have any utility/tool?Kindly advise me.
There is no native utility, but it can be scripted, and executed (provided the user can launch that script as Administrator, in order to have access to regedit and other admin tools)
For changing the albs service account in the Windows service, you would use sc (after stopping the service with net stop): see "How do I determine via Windows command line whether ALBD service is running?"
And here is an example for fix_prot using aliases.
You're likely to need to remove and recreate the views. Fix_prot may remove the view's additional group information, which will cause frustratingly intermittent issues accessing elements not owned by the view's primary group.
Fix_prot only coincidentally works on views. Its real purpose is to make it so you can register and tag a VOB, and then use protectvob to put the rest of the groups back.
There is no tool to restore view additional groups.
If you're going through with fix_prot on the views, you'll need to do it as step 4 and not 5 as the view won't register unless you at least do a fix_prot to replace the CC admin group.
Related
All,
I have no idea how Windows service works, just curious when we register a windows service(such as auto run a server after reboot), if it requires a user profile to load info(such as pulling data from somewhere else), what user profile does it load?
Thanks,
You can select what user run each service registered and the system comes with users assigned per service. The most used by the system is SYSTEM.
To check this you have to:
Go to services.
Right click on the desired service and properties.
Go to the Log on tab and check.
If the Local System account is selected the username is SYSTEM which has special permissions on almost all folder and Windows sections including users' profiles data.
By the other hand if you would like to do something special with an specific account you can tell the system the service will start with the account specified. Just make sure to update the password information every time the user change it.
Regards,
Luis
i have a MSI installation package that is installed as SYSTEM User and adds an active setup entry to the registry. This setup makes sure when a new user(new = that has not executed this setup until now) is logging on msiexec adds all missing registry entries.
In the MSIEXEC i need to do a net use to mount the users home directory. This cannot be done as system user and needs to be done in the user context.
However i seem to be completely unable to detect that the setup is currently running on the user context. Thats why i thought it would be nice to give additional parameters to the StubPath in the active setup entry. I tried NETUSE=1. This however did nothing. The setup just ignored this parameter and uses the parameter given during installation. So NETUSE stays 0.
Any ideas what kind of condition i could use for my custom net-use action?
Why is an MSI mounting a users home directory? I would write a small utility to do all this work and just have the MSI put it in the Run registry key. Install once per machine as System and then when the user logs in the utility gets called and does whatever per-user work you need to have done.
If the installer legitimately needs to populate per user registry data then that is fine to continue the active setup pattern.
You can try to use your own custom action configured to run only when the LogonUser property is different tan SYSTEM.
(Skip to the bottom for the TLDR version.)
OK - so I have searched (really!) and all other UAC articles I have found seem to center on enabling, disabling, detecting or hiding UAC. My issue is not one of those, so here goes:
My user used to have the standard dual-token setup where I was in the Administrators group and the UAC's Consent UI would just ask me if I wanted to proceed. Now, we have separate administrative-level accounts that we need to use, and I have to authenticate with this new user. The problem I am having is that previously, starting an app as Administrator just elevated my current user, where now if I use the credentials of the new administrative user, whatever I am running runs AS that new user.
As an example, previously elevating CMD and typing whoami into the command prompt used to return my normal/current user, where it now returns the new administrative user.
This has serious negative consequences - since this is a new user, and an Administrative-level one, if any files are created using this new user, my normal user cannot write to or delete them unless I manually adjust permissions and ownership. If I use my development environment under the new account (e.g. I need to debug a service or work with a driver) and rebuild something, I end up with a bunch of files that I cannot manipulate unless I am an administrator. Likewise if I add a file while running as this new account - my SCM tool will not be able to update that file later unless it also runs under this new administrative account.
Also, Since a profile is associated with this user, things run under a completely different environment (different %USERNAME%, %USERPROFILE%, %LOCALAPPDATA%, etc.)
Installing an application will also work incorrectly if it is installed just for the current user (e.g. the "Just Me" option), instead of for all users. Things that are licensed to/in my normal user account also fail to function if run under the new account, because things are running as that new user.
The ripple effects of this change are getting larger and larger the more I work with it. So...
[TLDR] Is there a way to get temporary elevation of the current user without that user having the normal dual-token setup you get from being in the Administrative group? Or are you stuck with the impersonation behavior?
A question that has stumped me for a while. I know this is possible over domains using Active Directory and all the rest, but what about on a basic local machine running on a basic network with many users.
Say this local machine is a communal work machine, which anyone with an account can use. All accounts are local, and are not roaming or on a domain, they are local to the machine.
Each user has different privileges, and are separated by groups.
While trying to create a group policy for a certain group, the group doesn't actually show up in the list. All that shows up in the list, are the local accounts individually, and two categories/groups: Administrators and Non Administrators
Where are the other groups? Why can I not create multiple policies specific to each individual group (Group1, Group2, Group3) that I have created?
The selection text quotes: "Local Users and Groups compatible with Local Group Policy". This seems to say that the groups I create seem not to be compatible with Group Policy?
Is there any fix to make custom groups 'Compatible' with Group Policy? Perhaps a registry or DLL fix?
Go to the Group Policy Management Console (gpmc.msc) and navigate to the required Organisational Unit. Right click, and select "Create a GPO..." and give it a name.
Right click on the newly created Group Policy Object, and deselect "Link Enabled" to prevent it from applying before you have finished configuring it.
Configure your GPO, and in the GPO Security Filtering panel, you are able to Add/Remove specific Active Directory users, groups and computers in which you want your GPO to apply to.
Hope this helps you
I have 2 processes. One of them is running under admin account, second - under user account with no permissions to admin processes. They need to see each other and compare the path, from where this processes where executed. But first (user) process can't get the path of the second process. Getting path using CreateToolhelp32Snapshot -> OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION) -> QueryFullProcessImageName is not applicable because it works in Vista, Win7 and higher, and I need solution for lower versions of Win.
So, how can I give permissions for user process to see the path of admin process, or how can I share privileges of admin process for the user using Access Tokens or using SetNamedSecurityInfo ?
using delphi desirable.
You can alter this, yes (*) - but you really should reconsider your logic. For example, admin process can open shared MMF with predefined name and store any information you need. You can share this MMF to any user or group you want (you should consider giving read-only access only). This is much safer than opening entire process to out world.
(*) In admin process: OpenProcess, get token and security descriptor, modify DACL to include new right for the desired user account or group, set token/SD back.