https://0-www.youtube.com.millie.wpbpl.com/watch?v=Nod7cpxzxLc
Tuesday, February 10, 2015
Tuesday, December 30, 2014
Could not obtain exclusive lock on database ‘model’. Retry the operation later
Error: 1807 Could not obtain exclusive lock on database ‘model’. Retry the operation later
Error:
TITLE: Microsoft SQL Server Management Studio
------------------------------
Create failed for Database 'Test'. (Microsoft.SqlServer.Smo)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.50.1600.1+((KJ_RTM).100402-1539+)&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Create+Database&LinkId=20476
------------------------------
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
------------------------------
Could not obtain exclusive lock on database 'model'. Retry the operation later.
CREATE DATABASE failed. Some file names listed could not be created. Check related errors. (Microsoft SQL Server, Error: 1807)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.50.1600&EvtSrc=MSSQLServer&EvtID=1807&LinkId=20476
------------------------------
BUTTONS:
OK
------------------------------
Solution:
Solution 1:
Disconnect and Reconnect your SQL Server Management Studio’s session. Your error will go away.
Solution 2:
Root Cause: Root cause of this error may be one of the following reason
1. Somebody exclusively open the Model database in different session
2. If more than one create database statements attempt to run simultaneously
How to identity:
Use master
GO
IF EXISTS(SELECT request_session_id FROM sys.dm_tran_locks
WHERE resource_database_id = DB_ID('Model'))
PRINT 'Model Database being used by some other session'
ELSE
PRINT 'Model Database not used by other session'
So we can identify that whether the Model database being execlusively used by any session.., If you found anybody using the Model database execlusively, You can identify what kind of statement being used by the session...using the script given below
SELECT request_session_id FROM sys.dm_tran_locks
WHERE resource_database_id = DB_ID('Model')
The script will return the session ID (i.e: 52)
We have to identity what kind of query/activity being performed by this session(52).
DBCC InputBuffer(52)
EventInfo column returns the query performed, Based on that, you have to decide whether the Session ID(52) can be Aborted/ Not. If you want to abort the session(52),
run the command
Kill 53
Now you can try to create a new Database..!
TITLE: Microsoft SQL Server Management Studio
------------------------------
Create failed for Database 'Test'. (Microsoft.SqlServer.Smo)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.50.1600.1+((KJ_RTM).100402-1539+)&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Create+Database&LinkId=20476
------------------------------
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
------------------------------
Could not obtain exclusive lock on database 'model'. Retry the operation later.
CREATE DATABASE failed. Some file names listed could not be created. Check related errors. (Microsoft SQL Server, Error: 1807)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.50.1600&EvtSrc=MSSQLServer&EvtID=1807&LinkId=20476
------------------------------
BUTTONS:
OK
------------------------------
Solution:
Solution 1:
Disconnect and Reconnect your SQL Server Management Studio’s session. Your error will go away.
Solution 2:
Root Cause: Root cause of this error may be one of the following reason
1. Somebody exclusively open the Model database in different session
2. If more than one create database statements attempt to run simultaneously
How to identity:
Use master
GO
IF EXISTS(SELECT request_session_id FROM sys.dm_tran_locks
WHERE resource_database_id = DB_ID('Model'))
PRINT 'Model Database being used by some other session'
ELSE
PRINT 'Model Database not used by other session'
So we can identify that whether the Model database being execlusively used by any session.., If you found anybody using the Model database execlusively, You can identify what kind of statement being used by the session...using the script given below
SELECT request_session_id FROM sys.dm_tran_locks
WHERE resource_database_id = DB_ID('Model')
The script will return the session ID (i.e: 52)
We have to identity what kind of query/activity being performed by this session(52).
DBCC InputBuffer(52)
EventInfo column returns the query performed, Based on that, you have to decide whether the Session ID(52) can be Aborted/ Not. If you want to abort the session(52),
run the command
Kill 53
Now you can try to create a new Database..!
Friday, December 5, 2014
Exchange Server 2010 Database Availability Group Installation Step by Step
Exchange Server 2010 introduced a new high availability feature called the Database Availability Group (DAG). This tutorial describes how Database Availability Groups work in Exchange Server 2010, as well as demonstrating the steps for deploying a DAG using Exchange Server 2010 SP1 and Windows Server 2008 R2.
EXCHANGE SERVER 2010 DATABASE AVAILABILITY GROUP OVERVIEW
A Database Availability Group is a group of up to 16 Exchange Server 2010 servers that are installed with the Mailbox server role. Each server that is a member of the DAG is capable of hosting active or passive copies of mailbox databases that reside on servers in the group.
For example, a Database Availability Group may consist of three Exchange Server 2010 Mailbox servers, each configured with a single Mailbox database. Each server that is a member of the DAG can host either an active or passive copy of each of the three total mailbox databases.
The foundation of an Exchange Server 2010 Database Availability Group is Windows Failover Clustering. However unlike traditional Exchange server clusters which existed in an active/passive state, and in which the entire cluster group needed to failover to an alternative node together, with Exchange 2010 DAGs each mailbox database can failover (or switchover, if it is a deliberate move) to another DAG member independent of the other mailbox databases in the DAG.
This means that any given Mailbox server in the DAG can host all, some or none of the active mailbox copies at any given time. This capability provides two immediate advantages over previous clustering models:
- All of the Mailbox servers within the Exchange 2010 DAG can be active and in use at all times to some capacity
- Each mailbox database can failover/switchover when necessary without impacting the mailbox users connected to other mailbox databases within the DAG, for example when installing updates on DAG members
UNDERSTANDING QUORUM FOR EXCHANGE SERVER 2010 DATABASE AVAILABILITY GROUPS
Because the Database Availability Group utilizes an underlying Windows Failover Cluster the concept of quorum applies. If you are not familiar with quorum consider it as basically a voting process in which a majority of voting members must be present to make a decision.
For a cluster this means that an odd number of members must be involved in the voting process for a majority decision to be made. How this applies to an Exchange Server 2010 DAG is that if you deploy a DAG with just two Mailbox servers as members (or any even number up to 16), then neither server is able to determine by majority vote whether it should make its own copy of a given mailbox database active.
To achieve quorum for a DAG with an even number of member servers another server in the same site is designated as a File Share Witness for the cluster. This is typically a Hub Transport server though it can technically be any compatible Windows server.
DATABASE REPLICATION IN EXCHANGE SERVER 2010 DATABASE AVAILABILITY GROUPS
There are two ways that mailbox database replication occurs between Exchange Server 2010 DAG members.
In Exchange Server 2010 RTM “file mode” replication is used. With file mode replication as each transaction log is written and then closed off (once it reaches 1Mb in size) it is then copied to each member of the DAG that also holds a copy of that mailbox database. The other members receive the file into their replay queue, and then replay the transaction log file into their own passive copy of the database.
File mode replication works fine but has an obvious shortcoming in that any transaction logs that have not yet been shipped to other servers in the DAG can be lost if the Exchange server hosting the active database copy fails. In those cases one of the other DAG members is able to bring their copy of the mailbox database online and then request missing emails be resent from the transport dumpster of Hub Transport servers within the site.
In Exchange Server 2010 SP1 file mode replication is used to bring mailbox database copies into sync with each other (eg during the initial sync process when a new database copy is added). Once they are in sync the DAG members switch to “block mode” replication. In block mode replication each database transaction is written to the log buffer on the active server and also sent to the log buffer of DAG members hosting passive copies of the database.
When the log buffer becomes full each DAG member then builds their own transaction log files from their own log buffer. Block mode replication has an advantage over file mode replication in failure scenarios, because each DAG member is completely up to date with all changes to the active database.
Note that Public Folder databases can reside on Mailbox servers that are members of a Database Availability Group, however they are not replicated by the DAG itself. Instead you must use Public Folder replication to provide redundant copies of Public Folder databases.
OTHER ADVANTAGES OF EXCHANGE SERVER 2010 DATABASE AVAILABILITY GROUPS
Before we proceed with an example of how to install an Exchange Server 2010 DAG I will also mention some of the other advantages of Database Availability Groups.
- Unlike previous versions of Exchange Server (particularly Exchange Server 2007) Exchange Server 2010 has just one high availability feature for Mailbox servers for all high availability deployment scenarios
- When you create a Database Availability Group the underlying Windows Failover Cluster is automatically created and configured for you
- A Database Availability Group can be created at any time without requiring Exchange Server 2010 to be removed and reinstalled from the server, unlike previous versions that required that clusters be established first before Exchange was installed
- Exchange Server 2010 DAG members can host other server roles, unlike Exchange Server 2007 that prevented clustered Mailbox servers from hosting other roles
EXCHANGE SERVER 2010 INSTALLATION STEP BY STEP
In this tutorial I will demonstrate the installation of an Exchange Server 2010 Database Availability Group on Windows Server 2008 R2.
For this tutorial the following Exchange servers have already been installed.
- EX1 – Exchange Server 2010 SP1 Mailbox server
- Primary interface: 192.168.0.32/24
- Secondary interface: 10.0.5.1/30
- EX2 – Exchange Server 2010 SP1 Mailbox server
- Primary interface: 192.168.0.33/24
- Secondary interface: 10.0.5.2/30
- EX3 – Exchange Server 2010 SP1 Client Access and Hub Transport server
- Primary interface: 192.168.0.34/24
Note: for details of how to deploy these server roles see Installing Exchange Server 2010 Pre-requisites on Windows Server 2008 R2 and Installing Exchange Server 2010.
Each of the Mailbox servers has been configured with its own mailbox database.
- EX1 – Mailbox Database 01
- EX2 – Mailbox Database 02
Note: in Exchange Server 2010 each mailbox database must have a unique name within the organization.
Because the Mailbox servers are configured with dual interfaces it is important to make sure that the secondary interface is not configured to register itself in DNS. Open the TCP/IPv4 properties for the secondary interface one each server, click the Advanced button, navigate to the DNS tab and untick Register this connection’s address in DNS.
CREATING THE DATABASE AVAILABILITY GROUP
Log in to one of the Mailbox servers and launch the Exchange Management Console. Navigate to Organization Config/Mailbox and choose New Database Availability Groupfrom the action pane.
When the New Database Availability Group wizard starts give the DAG a name, specify theWitness server, and also specify the file path for the Witness server to use.
Click on the New button to create the new Database Availability Group, and then clickFinish to close the wizard.
ADDING DATABASE AVAILABILITY GROUP MEMBERS
Right-click the newly created Database Availability Group and choose Manage Database Availability Group Membership.
Click the Add button and select the Mailbox servers that you wish to make members of the DAG.
Click the Manage button to commence adding the Mailbox servers to the DAG. This involves installation and configuration of Windows Failover Clustering on the servers, so it can take a few minutes to finish.
After it has finished the next step is to configure the DAG networking.
CONFIGURE DATABASE AVAILABILITY GROUP NETWORKING
Right-click the newly created Database Availability Group and choose Properties.
Select the IP Addresses tab, click the Add button and add a static IP address for the Database Availability Group.
You will notice that the Database Availability Group has been automatically configured with DAG networks for the subnets that the DAG members have network interfaces connected to.
Open the Properties of each DAG network and configure them with meaningful names. If you have configured your network to have a dedicated replication network for the DAG then you should disable replication on the DAG network that is intended for MAPI communications (ie client connections).
ADDING MAILBOX DATABASE COPIES TO DAG MEMBERS
With the Database Availability Group established and the networking configured you can now add mailbox database copies to other DAG members.
In the Exchange Management Console navigate to Organization Config/Mailbox and choose the Database Management tab. Right-click a mailbox database and select Add Mailbox Database Copy.
Click the Browse button and choose the Mailbox server to add the database copy to.
Click the Add button to add the mailbox database copy and then click Finish to close the wizard.
The Exchange servers will now commence seeding the replica servers with an up to date copy of the database and all of the current transaction log files. Depending on the amount of data to be replicated this may take some time.
Repeat the same process for any other mailbox databases you wish to add database copies for.
Thursday, December 4, 2014
Step-by-Step FRS to DFSR Migration Guide for Windows 2008 and 2008 R2
This article is a step-by-step FRS to DFSR migration guide from FRS replication of domain controllers to the newer DFSR replication.
Overview
Domain controllers use a special shared folder named SYSVOL to replicate logon scripts and Group Policy object files to other domain controllers. Windows 2000 Server and Windows Server 2003 use File Replication Service (FRS) to replicate SYSVOL, whereas Windows Server 2008 uses the newer DFS Replication service when in domains that use the Windows Server 2008 domain functional level, and FRS for domains that run older domain functional levels.
To use DFS Replication to replicate the SYSVOL folder, you can either create a new domain that uses the Windows Server 2008 domain functional level, or you can use the procedure that is discussed in this article to upgrade an existing domain and migrate replication to DFS Replication.
Applies To: Windows Server 2008, Windows Server 2008 R2
You may also experiencing one or more of the following errors:
A. When running dcdiag /e /c on a domain controller, test: VerifyEnterpriseReferences fails with error:
Starting test: VerifyEnterpriseReferences
The following problems were found while verifying various important DN references. Note, that these problems
can be reported because of latency in replication. So follow up to resolve the following problems, only if
the same problem is reported on all DCs for a given domain or if the problem persists after replication has
had reasonable time to replicate changes.
[1] Problem: Missing Expected Value
Base Object: CN=DC01,OU=Domain Controllers,DC=showmehowtodoit, DC=com
Base Object Description: “DC Account Object”
Value Object Attribute Name: msDFSR-ComputerReferenceBL
Value Object Description: “SYSVOL FRS Member Object”
Recommended Action: See Knowledge Base Article: Q312862
The following problems were found while verifying various important DN references. Note, that these problems
can be reported because of latency in replication. So follow up to resolve the following problems, only if
the same problem is reported on all DCs for a given domain or if the problem persists after replication has
had reasonable time to replicate changes.
[1] Problem: Missing Expected Value
Base Object: CN=DC01,OU=Domain Controllers,DC=showmehowtodoit, DC=com
Base Object Description: “DC Account Object”
Value Object Attribute Name: msDFSR-ComputerReferenceBL
Value Object Description: “SYSVOL FRS Member Object”
Recommended Action: See Knowledge Base Article: Q312862
[2] Problem: Missing Expected Value
Base Object: CN=DC02,OU=Domain Controllers,DC=showmehowtodoit, DC=com
Base Object Description: “DC Account Object”
Value Object Attribute Name: msDFSR-ComputerReferenceBL
Value Object Description: “SYSVOL FRS Member Object”
Recommended Action: See Knowledge Base Article: Q312862
Base Object: CN=DC02,OU=Domain Controllers,DC=showmehowtodoit, DC=com
Base Object Description: “DC Account Object”
Value Object Attribute Name: msDFSR-ComputerReferenceBL
Value Object Description: “SYSVOL FRS Member Object”
Recommended Action: See Knowledge Base Article: Q312862
LDAP Error 0x20 (32) – No Such Object.
……………………. LIBRARY failed test VerifyEnterpriseReferences
……………………. LIBRARY failed test VerifyEnterpriseReferences
B. You may get various Group Policy errors event viewer such as 1000,1001,1058,1030. For example:
Description: Windows cannot access the file gpt.ini for GPO
CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=showmehowtodoit,DC=com
The file must be present at the location \\showmehowtodoit.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}
(Access is denied) Group Policy processing aborted.
CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=showmehowtodoit,DC=com
The file must be present at the location \\showmehowtodoit.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}
(Access is denied) Group Policy processing aborted.
C. SYSVOL folder contents differ across domain controllers.
All of the above problems are common errors that exist when domain controllers do not replicate correctly. The root cause according to Microsoft is that when you actually raise your domain and functional levels in an existing environment, active directory assumes that the replication is performed using DFSR between domain controllers even if the replication still happens using the FRS protocol. If you want to verify whether you are replicating using FRS or DFSR you may perform the following 3 checks.
Method 1: Open a PowerShell command and run the following cmdlet. If you are running FRS yet, you should get a warning that the migration has not been started yet. If you are running on DFSR you should get a return that the migration state is in the “Eliminated” step.
> dfsrmig /getglobalstate
Since we have not performed the migration steps, we will get the following error:
Method 2: Log on to a domain controller and examine under c:\Windows whether a SYSVOL_DFSRfolder exists. If it exist, it means you are already replicating using DFSR. In any other case you should have a SYSVOL folder and replicate using FRS.
Method 3: You may notice “File Replication Service” service running under services snap-in. This service will be disabled once the migration is complete.
Migrating to the Prepared State
The first step of the migration state is to get into the “Prepared” state. However, before actually triggering the process, we should make sure that the active directory is in a healthy state.
- On each domain controller in your domain you wish to migrate, open up a command prompt and type net share to verify that SYSVOL folder is shared and maps to the correct folder. the output should be something similar to the following:
Share name Resource Remark -------------------------------------------------------------------------------- […] NETLOGON C:\Windows\SYSVOL\sysvol\showmehowtodoit.com\SCRIPTS Logon server share SYSVOL C:\Windows\SYSVOL\sysvol Logon server share - Use Registry Editor on each domain controller in the domain to navigate toHKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters and verify that the value of the SysVol registry entry is [drive:\]Windows_folder\SYSVOL\sysvol, and that the value of the SysvolReady registry entry is 1.
- Verify that the DFS Replication service is listed with the values of Started in the Status column and Automatic in the Startup Type column.
- Open up a command prompt and type repadmin /ReplSum to get a status of replication between domain controllers.
- While having the command prompt window open, run dcdiag tool and examine the output for possible error.
Once you are confident that your active directory health is good, we may trigger the migration process. Log on to your primary domain controller (PDC).
- Open up a PowerShell or command prompt window and type dfsrmig /setglobalstate 1. You should get informed that the new global migration state is now set to “prepared”.
- Type dfsrmig /GetMigrationState. You will probably receive a warning that the global migration state has not reached a consistent state (yet). This is normal, since domain controllers now have to perform various tasks related to the migration. Try re-running the command after some time.
- Check on you domain controllers under c:\windows if a new SYSVOL_DFSR folder has been created.
- Type dfsrmig /GetMigrationState to verify that the global state replication has reached a consistent level between domain controllers.
- Now we are ready to proceed to the next step, migrating to the “Redirected” state. Typedfsrmig /setglobalstate 2to go from the “Prepared” state to the “Redirected” state. Your output should be similar to:
- Examine the migration process by typing dfsrmig /GetMigrationState. Once the domain controllers has reached a consistent state, proceed to the next step.
- We are now ready to get to the final stage of the migration process. Once the migration process is set to the next ‘ELIMINATED’ state, it cannot be reverted under any circumstances. Therefore, ensure that SYSVOL replication using the DFS Replication service is healthy, before committing entirely to finalizing the migration process and re-run the diagnostic commands shown earlier to verify active directory health. The most important precaution is to ensure that all domain controllers have successfully migrated to the ‘REDIRECTED’ state before changing the global migration state to the ‘ELIMINATED’ state. This can be achieved by typing dfsrmig /getmigrationstate.
- Once you ensured that the replication health is good, type dfsrmig /setGlobalState 3. There will be a series tasks that now will be performed in the backround such as: If the FRS service is running on the domain controller, it is then stopped. It deletes the Active Directory configuration settings required for the FRS service to replicate the SYSVOL share between domain controllers. Thus, all global settings of the FRS service that pertain to the SYSVOL content set are deleted. The ‘SYSVOL’ folder which was being replicated by the FRS service is now deleted. Note that if you have Windows Explorer or the command shell open on the domain controller and if the current directory corresponds to the ‘SYSVOL’ folder location, the DFS Replication service will be unable to delete this folder owing to sharing violations. You should have a similar result as below.
You may notice that the SYSVOL folder is deleted. Instead, SYSVOL_DFSR is present.
FRS service is disabled under services.
Non-authoritative SYSVOL restore (FRS)
When you are working in Active Directory environment you may fall into this problem, especially in case where you have many Domain Controllers. Sometimes you may figure out that one or more Domain Controllers are out of date with SYSVOL replication.
Each Domain Controller has its own folder where GPOs and scripts are saved. This folder is located under %WINDIR%\SYSVOL\domain (by default, if you changed that location during DC promotion, you need to refer to your own location).
There are 2 folders:
- Policies where Group Policies are saved (%WINDIR%\SYSVOL\domain\Policies)
- Scripts where logon scripts or other files are saved (%WINDIR%\SYSVOL\domain\Scripts shared as NETLOGON)
If a DC does not replicate SYSVOL you can see that some Group Policies (GPOs) or scripts are not available on DC(s) in SYSVOL\domain folder on particular DC. Another symptom may be that all GPOs are in place but they are not updated.
When you notice one of these behaviors, you would need to do non-authoritative SYSVOL restore which re-deploys SYSVOL data from working Domain Controller (holding PDC Emulator operations master role).
How to be sure if you need non-authoritative SYSVOL restore? There is no simple answer because that depends on the size of your Active Directory and number of Domain Controllers.
When we can decide to start this kind of retore ?
- one DC out of couple does not replicate SYSVOL
- a few DCs out of many do not replicate SYSVOL
- more than few but less than 50% of them do not replicate SYSVOL
above examples are typical scenarios for non-authoritative SYSVOLrestore.
Let’s see how you to do that.
First of all, you need to find out which DC or DCs does/do not replicate SYSVOL. Then you have to start SYSVOL restore.
When you see an empty SYSVOL, this may suggest that Domain Controller initialization where not finished after server was promoted. Active Directory database was replicated but SYSVOL was not. In this case, you can simply perform non-authoritative restore and SYSVOL should be replicated.
Empty SYSVOL folder
Another case is when DC, is not up to date with SYSVOL. Some policies are missing and non-authoritative SYSVOL restore would be helpful.
Missing Group Policies under SYSVOL
When you log on to Domain Controller with PDC Emulator operation master role, you should see that there are more policies than on those faulty Domain Controllers
All Group Policies on DC with PDC Emulator role
So, you can see that those Domain Controllers need SYSVOL restore to have all data up-to-date.
Now, it’s time to play with non-authoritative SYSVOL restore. Log on to the DC which is out of replication with SYSVOL and stop File Replication Service (NtFRS) from command-line/elevated command-line. Type
net stop ntfrs
Stopping File Replication Service
Now, you need to change some setting in Windows registry.
Warning! Be careful, do not change other entries than showed in this artcile, you may destroy your server!
You need to open registry editor from run box
Executing registry editor
Now, you need to find below key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
BurFlags value location
and change BurFlags value from 0 to D2 (hexadecimal) by editing it
Changing BurFlags value
Before you will start FRS service, I would suggest to remove all content from those 2 folders
- %WINDIR%\SYSVOL\domain\Policies
- %WINDIR%\SYSVOL\domain\Scripts
Note! (by default, if you changed SYSVOL location during DC promotion, you need to refer to your own location)
Warning! When you set up D2 BurFlags value, you need to know that during restoration time, your DC is prevent to be a Domain Controller! So, you need to be careful in locations/Sites where you have only single DC or you are going for authentication over WAN-link!
Now, it’s time to start File Replication Service. Type in command-line
net start ntfrs
Running File Replication Service
When you refresh (F5 key) registry editor, you should see that BurFlgs values has changed back to 0
BurFlags value reset
and you should also check “File Replication Service” event log. Please check if event id 13565 appeared. That means, server has initiated SYSVOL replication and you need to wait a while. You have to refresh event log from time to time and check if these event IDs appeared:
- 13553
- 13516
when you can see them, SYSVOL replication is over and your Domain Controller is up-to-date.
SYSVOL re-initialized
SYSVOL re-initialized
Verify if SYSVOL share is available on your Domain Controller, type in command-line
net share
SYSVOL share verification
go to %WINDIR%\SYSVOL\domain\Policies and check if data is replicated
SYSVOL content verification
That’s all! Everything you need to do is to repeat all those steps on each Domain Controller which does not replicate SYSVOL volume.
Done!
Subscribe to:
Posts (Atom)