• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 799
  • Last Modified:

Exchange 2007 SCR problems on MS Server 2008

Afternoon all.  I have a very simple Exchange 2007 environment.  Initially we had one Exchange 2007 SP1 all-in-one server, no edge or UC running on Windows server 2008. We installed another server with the same Exchange config with MB, HUB, and CAS on WIN2k8.  This  server was installed for DR purposes therefore we are trying to enable SCR.

When I run enable-storagegroupcopy -Identity SG  -StandbyMachine server.domain.com -ReplayLagTime 0.0:0:0 it appears to enable. Event log states the enable copy was successful.  I then seed the standby machine with no problem. Then if I run get-StoragegroupCopyStatus -Identity SG -StandbyMachine server.domain.com | fl from the standby machine I get the below results:

Identity                         : Server\SG
StorageGroupName                 : SG
SummaryCopyStatus                : NotConfigured
NotSupported                     : False
NotConfigured                    : True
Disabled                         : False
ServiceDown                      : False
Failed                           : False
Initializing                     : False
Resynchronizing                  : False
Seeding                          : False
Suspend                          : False
CCRTargetNode                    :
FailedMessage                    :
SuspendComment                   :
CopyQueueLength                  : 0
ReplayQueueLength                : 0
LatestAvailableLogTime           :
LastCopyNotificationedLogTime    :
LastCopiedLogTime                :
LastInspectedLogTime             :
LastReplayedLogTime              :
LastLogGenerated                 : 0
LastLogCopyNotified              : 0
LastLogCopied                    : 0
LastLogInspected                 : 0
LastLogReplayed                  : 0
LatestFullBackupTime             :
LatestIncrementalBackupTime      :
LatestDifferentialBackupTime     :
LatestCopyBackupTime             :
SnapshotBackup                   :
SnapshotLatestFullBackup         :
SnapshotLatestIncrementalBackup  :
SnapshotLatestDifferentialBackup :
SnapshotLatestCopyBackup         :
OutstandingDumpsterRequests      :
DumpsterServersNotAvailable      :
DumpsterStatistics               :
IsValid                          : True
ObjectState                      : Unchanged

I then find in the event log Source: MSExchangeRepl Event ID: 2047 "The directory \\server\0c5f1715-ac6d-46ee-b34e-a9542175d27f$ required by the Microsoft Exchange Replication Service for Server\SG does not exist. Check the file system and its permissions.
Initially I found that only the security group Microsoft Exchange Servers had access to this share but no share permissions were given to this group  I changed the share permissions to read and restarted the replication service and system attendant.  NTFS permission look okay.  After making this change and resuming the copy I still get the above error.  I then opened up the share to Everyone Read access Everyone Read NTFS permissions and it still fails.

Both Exchange servers are in the Exchange server security group.  All firewall profiles on both servers are off and the service is stopped.  I could find no DNS problems.  EBPA finds nothing relevant.

These are HP servers with NIC teaming enabled on the source but not the target.  I was leaning in that direction buit when we tried to break the team on the target we could not get it to break correctly (very suspect!) and had to put it back in place as this mail server is in production and we could not mess with this further during business hours.

I have reviewed many posts here and thought I was on to something but I am completely out of ideas as nothing has worked.  All suggestions would be most appreciated.  Thanks!!
0
ENTPF
Asked:
ENTPF
1 Solution
 
ENTPFAuthor Commented:
All I wanted to post that the NIC Teaming was the culprit to the problem.  After recreating the team I was quickly able to enable the Storage Group copy with no problems at all.  Thanks.
0

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now