An Avanade Blogging Community

Group polilcy Preferences can replace your loginscripts and other scripts.. but are your clients ready for GPP?

http://blog.studiographic.nl/?p=256

The admin cannot be locked out.. or can he?

http://blog.studiographic.nl/?p=268

DHCP is the mechanism that gives most client these days the tools (ip address) for connectivity. Most companies however do not realize the importance of the DHCP service and do not cluster nor have another server as standby when the DHCP server fails. If the DHCP server fails, most clients will not receive a new ip address and will seize to work on the network. While clustering is improved in Windows 2008 and sort of made easy for administrators, most of them are reluctant to implement a failover cluster for DHCP. In Windows 2008 R2 we have Split-Scopes, remember the 80-20 rule for DHCP servers, it kinda the same, but then made easy. For this article we have a single domain controller and two Windows 2008R2 servers.

Read entire post>>

Password policies can help administrators secure their environment, letting users change their passwords on regular basis makes it harder for hackers to get in to a system by guessing a password. There is one group of accounts though that usually do not have the password policy applied to.. they almost never change their password and when they do.. it is a load of work for the admin, there is service downtime involved.. and after the password has been changed.. it will be not be changed for a long time.. Yes, I’m talking about Service Account.. the accounts administrators usually apply the “Password Never Expires” option to. These accounts usually have more rights to systems, perhaps even local Administrator access to machines (like SQL or mail) or even worse (Don’t tell me you have these in place) Domain Admin rights. Changing passwords for these accounts is crucial to the security of your environment. To make life easier Windows 2008 R2 introduces the Managed Service Accounts, with these, you can easily change the password of an account, and the client computers where these service accounts are operational will change the password in the service configuration.

Read the rest of this entry »

Some of you might be using Windows 7 already and have noticed that the Wireless solution for Windows Home Server does work well with Windows 7. In fact, the computer does not challenge the user for a username or password, but just tells you it cannot connect. This is because Windows 7 has a different default setting for WPA-Enterprise authentication to wireless networks. By default the client computer will try to authenticate the user including the computername. IAS warnings in the eventlog are a result of Windows 7 computers trying to authenticate.

More

The introduction of Windows 2008 brought us the famous Read-Only domain controller, the domain controller without passwords (unless explicitly approved) and one-way replication. That one-way replication also applied to the SYSVOL share. Sysvol is replicated by either FRS or DFSR depending on the initial setup of the domain. If you have upgraded your domain from Windows 2000 or Windows 2003 to Windows 2008 SYSVOL is still using FRS to replicate. When you have initially deployed Windows 2008 and set the forest functional level to use the Windows 2008 standards; DFSR is used. Usually the replication of Sysvol is two-way, you can change the contents on each domain controller and those changes are replicated to all domain controllers.

If you made changes to the SYSVOL folder on an RODC (2008), however, these changes are overwritten with the next replication cycle when you have DFSR. When you have a Windows 2008 R2 RODC the SYSVOL share will automatically be marked as read-only so you cannot make any changes.

When you have a mixed 2003/2008 domain, or did not start with the forest functional level at 2008; SYSVOL still replicates through the FRS method, and in that case horrible things can occur: If you change a file on the RODC SYSVOL that replicates through the FRS method the file get’s stamped placed in the queue for outbound replication (which will never occur) and if you make enough changes the FRS on the RODC will actually shutdown! In any case, the changed file will never go outbound. To circumvent this behavior some Administrators ACL’d the SYSVOL on the Read Only domain controller, but again, those changes are also marked for outbound delivery. In any case, if you are running in a mixed environment, upgrade those last domain controllers and do not forget to migrate your SYSVOL to use DFSR.

Why?

DFSR is more efficient, scalable and reliable; it uses Differential replication with compression instead of replicating the entire file. It is more flexible (scheduling/bandwidth throttling wise) and even better has a self-healing mechanism that protects is from database corruptions! No more D0, or D5’s needed.

How do you migrate?

The sysvol migration can be achieved through the DFSRMIG program. This little program requires the domain to be in forest functional level 2008. There are 4 steps in migrating the SYSVOL replication technique. These steps are 0 to 3 and are:

0 – Start
1 – Prepare
2 – Redirect
3 – Eliminate

When we give the order to prepare for the migration, each domain controller will actually create a new SYSVOL folder and fill that up with the contents of the current SYSVOL folder, replication for that folder will start automatically. The new Sysvol folder (called SYSVOL_DFSR) will be created on the same location as the current SYSVOL folder. If you have for example places SYSVOL on D:\, the new folder will be D:\SYSVOL_DFSR.

In the redirect state the share is swapped on each domain controller and you are actually running your sysvol with DFS Replication. In the eliminate phase the old SYSVOL is deleted and FRS is stopped for Sysvol replication.

DFSRMig /setGlobalState 0 is the starting point, to verify the global state of the migration, use the /getMigrationState command. This will tell you if all domain controllers in the domain have reached the state you wanted and if not, which ones are still out of Sync.

If you want to know the last command (and state you have ordered), use the /getGlobalState option:

In the above screenshot, you see that the five domain controllers that make up this domain are still in the start state while we have given the “Prepare” command

The process is coordinated by the PDC emulator domain controller, therefore it could take a while before all domain controllers are in sync. You can actually force the process a bit by forcing replication using the command: repadmin /syncall /AeD, then force the DFSR to poll the Active Directory for changes: dfsrdiag polladd /Member:<dc>

Well you can continue to set the Global State to 3 to finish the migration. If you want to roll-back however, please do so before state 3 by setting the previous state. After state 3 there’s no way back.

If you want more information on where the current SYSVOL is hosted, and where the new location is aswell as other info on the DFSR use the DFSRDiag DumpADCfg command:

Above you see the servername and the new sysvol folder just created by the prepare command.

Continue all the steps above until you have completed migration state 3.

If you want more info.. go to the Storage Team Blog:

http://blogs.technet.com/filecab/archive/2008/02/08/sysvol-migration-series-part-1-introduction-to-the-sysvol-migration-process.aspx

Make sure your start the command prompt with Administrative privileges, otherwise the join will fail:

After a (manual) reboot, the computer joined the domain: