ForensiT Homepage
Forum Home Forum Home > ForensiT Support > Domain Migration
  Active Topics Active Topics
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Multiple Issues Profwiz Corporate

 Post Reply Post Reply Page  12>
Author
Message Reverse Sort Order
  Topic Search Topic Search  Topic Options Topic Options
yarno View Drop Down
Newbie
Newbie


Joined: 08 Jul 2013
Online Status: Offline
Posts: 8
  Quote yarno Quote  Post ReplyReply Direct Link To This Post Topic: Multiple Issues Profwiz Corporate
    Posted: 11 Feb 2014 at 4:22am
Hi,
Thanks for your explaination and this is the way it should work, that is also what we agree.
But unfortunatly Profwiz is not working this way. The configured accounts in Profwiz have the right credentials, otherwise Profwiz is not able to pull the SID from the user in the new domain. Still it cannot determine (following your explanation) if there is a roaming profile configured in the new domain. I tested the acces to the shared folder, this is also not a problem for the B\administrator account.
As I told you I rebuilded the DC's from scratch and they are clean. The only GPO I created is in the old domain for running Profwiz at User logon.
 
What can I do about it?
Do you have a test environment so you can test my issue?
Or can you explain to me like I am a 4 year old kid how to solve this?
 
Thanks in advance
Back to Top
Support View Drop Down
Moderator Group
Moderator Group


Joined: 09 Nov 2006
Location: United Kingdom
Online Status: Offline
Posts: 1333
  Quote Support Quote  Post ReplyReply Direct Link To This Post Posted: 10 Feb 2014 at 9:52am
No where did we say that the profiles need to exist.

The whole point is that the profiles must not exist in the new domain. That is what all this is about. If a roaming profile already exists in the new domain it will over-write the local profile and the user will lose all their data.

Profwiz needs to check that the roaming profile does not already exist in the new domain. To do that it needs to know the profile path (from the user account object in AD) and it needs access to the parent folder where the roaming profile will be created.

If Profwiz cannot confirm that the roaming profile does not exist, it will force the user to use a local profile - and that is what you are seeing.
Back to Top
yarno View Drop Down
Newbie
Newbie


Joined: 08 Jul 2013
Online Status: Offline
Posts: 8
  Quote yarno Quote  Post ReplyReply Direct Link To This Post Posted: 10 Feb 2014 at 8:56am
Hi,
So you mean the profiles do exist in the old domain?
Or do they need to exist in the new domain?
 
Because either way will not work. In the old domain no user has a roaming profile, and in the new domain the profile path is configured but is emtpy because Windows needs to save the profile for the first time after the migration.
 
How can I solve this?
 
 
Back to Top
Support View Drop Down
Moderator Group
Moderator Group


Joined: 09 Nov 2006
Location: United Kingdom
Online Status: Offline
Posts: 1333
  Quote Support Quote  Post ReplyReply Direct Link To This Post Posted: 10 Feb 2014 at 5:03am
You need to ensure that Profwiz can check whether the existing profile exists on the network share.

Check the Profile Path on the "Profiles" tab of the user account object in AD: it is probably going to be something like \\Server\Share\Username Go to a workstation and logon as the <DomainAdmin> account you have specified in Profwiz.config, go to Start\Run and type \\Server\Share - you should be able to see the contents of the share, but not have access to any roaming profiles.
Back to Top
yarno View Drop Down
Newbie
Newbie


Joined: 08 Jul 2013
Online Status: Offline
Posts: 8
  Quote yarno Quote  Post ReplyReply Direct Link To This Post Posted: 08 Feb 2014 at 11:05am
So how can I fix this? The old domain has no roaming profiles. In the new domain I want to use roaming profiles. Tell me. What do I wrong? Is something wrong in the config?
Back to Top
Support View Drop Down
Moderator Group
Moderator Group


Joined: 09 Nov 2006
Location: United Kingdom
Online Status: Offline
Posts: 1333
  Quote Support Quote  Post ReplyReply Direct Link To This Post Posted: 08 Feb 2014 at 4:11am
You say you do not understand why Profwiz is changing the default option for the profile type, but we have already explained twice already. It is because it cannot determine whether a roaming profile already exists and so has to protect the local profile data from the possibility of being overwritten.
Back to Top
yarno View Drop Down
Newbie
Newbie


Joined: 08 Jul 2013
Online Status: Offline
Posts: 8
  Quote yarno Quote  Post ReplyReply Direct Link To This Post Posted: 07 Feb 2014 at 2:10pm
Hi,

I have figured it out. It has to do with the registry.
Windows has 3 options to decide what kind of profile it needs to deal with it.
Option 1 (Default): Let Windows decide if there is a local or roaming profile. This way there is no UserPreference key in the registry. Windows checks the ProfilePath to decide if the user has a local profile (ProfilePath empty) or has a roaming profile (ProfilePath configured in the AD).
Option 2: User has configured manually a local profile.
Userpreference has the value of 0. Windows does not check the ProfilePath.
Option 3: User has configured manually a roaming profile.
Userpreference has the value of 1. Windows checks the ProfilePath to load and save the profile.

For some reason Profwiz is changing the default option and checks the current domain if there is a local or roaming profile. If there is a local profile it is changing the registry for option 2, if there is a roaming profile it is changing the registry for option 3.

I do not understand why Profwiz is doing this? The only reason I can think of is precaution if someone has changed the setting manually to roaming but in the new domain there is no roaming profile. I think this can be solved in a different way?

The solution is to delete the UserPreference key in everyone's ProfileList. Or Profwiz changes there software so it it not creating the UserPreference keys and let Windows decide what to do.

Is this possible? Or do you have a script I can use in Profwiz to delete all the UserPreference keys what Profwiz has created? In Windows XP the key is in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList\**SID**\UserPreference , in Windows 7 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList\**SID**\Preference\UserPreference

I like to hear from you soon.
Many thanks, Jarno

Back to Top
yarno View Drop Down
Newbie
Newbie


Joined: 08 Jul 2013
Online Status: Offline
Posts: 8
  Quote yarno Quote  Post ReplyReply Direct Link To This Post Posted: 03 Feb 2014 at 12:01pm
Hi,

I solved the issue in Windows 7 that the domain admins is not member of the local administrators. What happened? I created a clone from the 2008R2 VM, and VirtualBox asks me if I want to use it for a new machine or want to keep the VM untouched. I choosed for new machine and assumed the VM would create a sysprep, what probably not happened. The SID's where from the 2 old DC's the same, what created the issue. Only the mac adress of the network card has changed. So I build up 2 new DC's from scratch what solved the issue.

So now I only have a issue with the roaming profiles.
I tried the following. In domain A no user has a roaming profile. In domain B 2 users have a roaming profile. I logged in with both the accounts with a roaming profile but the profile is not being saved as a roaming profile.
I created a new user in domain B. This user has no roaming profile. After login and logout, I gave the user a roaming profile path. What happened? The profile changed from local to roaming and the profile is being saved on the share.

Why is this not working with a migrated profile? Is there something different?
Back to Top
Support View Drop Down
Moderator Group
Moderator Group


Joined: 09 Nov 2006
Location: United Kingdom
Online Status: Offline
Posts: 1333
  Quote Support Quote  Post ReplyReply Direct Link To This Post Posted: 03 Feb 2014 at 4:41am
Profwiz does not create a local profile because the old domain does not have any roaming profiles. As I explained, Profwiz is not able to determine whether a roaming profile already exists for the new domain user account, so it defaults to a local profile in order to protect the local profile data.

You are right to say that a domain administrator account should be able to read the profilePath attribute on the user account object in AD, but there is no guarantee that it will have read access to the folder containing the profiles. It depends how the folder was set up.
Back to Top
yarno View Drop Down
Newbie
Newbie


Joined: 08 Jul 2013
Online Status: Offline
Posts: 8
  Quote yarno Quote  Post ReplyReply Direct Link To This Post Posted: 02 Feb 2014 at 3:07am
Hi,

I think that the following problem occurs:
The old domain has no roaming profiles, so Profwiz creates a local profile. When the profile is created (local), the client ignores the setting for roaming profile in the new domain.
I don't think it's a acces problem to the profile (administrator should be able to acces everything right?)

Or do I something wrong in the wizard? Or do I need to config a setting manually?

I work with snapshots, so I set the VM back before migrating and migrated the VM manually, but still the domain admins group is not member of the local administrators. I guess something is wrong with the OS, I'm creating a new VM right now to test again. The Windows XP VM works great.

Can you tell me what to do about the roaming profiles?

Regards, Jarno
Back to Top
 Post Reply Post Reply Page  12>

Forum Jump Forum Permissions View Drop Down



This page was generated in 0.016 seconds.