Archive

Archive for September, 2013

Volume Shadow Copy Service error event ID 12292

September 20, 2013 Leave a comment

Since we had change the SAN switch for one of our Exchange 2010 DAG nodes, Its started to fetch the event ID 12292 and VSS backup stoped working for this node.

Used below cmdlet to make sure exchange replication  writer and providers are working fine.

Vssadmin list writers

Vssadmin list providers

Started looking the registry value of VSS provider and matching the registry value with other DAG nodes which is working normally. During match, I found the “Start” Dword value is showing data value “0x00000004”.

In other DAG nodes this value was ““0x00000002” under “KLM\CCS\SYSTEM\SERVICES\SWPRV” .

If you falling under same kind of issue, I would suggest you to verify the registry value with working server for below Key’s.

1. On Exchange server, please run regedit, go to verify the following two registry keys. Make sure they are the same with another working server:

HKLM\CCS\SYSTEM\SERVICES\VSS\PROVIDERS

KLM\CCS\SYSTEM\SERVICES\SWPRV

2. Please Reboot Exchange server in Off-Business hours.

3. After reboot, please try to backup Exchange using Windows Server Backup tool.  Check if it is successful.

If still you are not bale to managed this working, As a Last resort you can try Re registering the Vss dlls

Re-registering Vss Dlls

cd /d %windir%\system32
net stop vss
net stop swprv
regsvr32 /s ole32.dll
regsvr32 /s oleaut32.dll
regsvr32 /s vss_ps.dll
vssvc /register
regsvr32 /s /i swprv.dll
regsvr32 /s /i eventcls.dll
regsvr32 /s es.dll
regsvr32 /s stdprov.dll
regsvr32 /s vssui.dll
regsvr32 /s msxml.dll
regsvr32 /s msxml3.dll
regsvr32 /s msxml4.dll
vssvc /register
net start swprv
net start vss

It does help in getting the Vss service to function properly

Advertisements

A myth – Removing GC/DC and Exchange CRY

September 9, 2013 Leave a comment

In the weekend I was working with my friend and helping him to remove his existing GC/DC and seen some interesting behavior about exchange which I thought to admit here which may be benefit to people those stuck into such Environment.

Current Setup

The environment has only one windows 2008 Server with all FSMO role installed and on top of that Exchange 2010 CAS,MBX,HUB role also installed (I know it’s not recommended 🙂 )

Requirement

They had installed one Exchange 2010 SP2 on Windows 2008 R2 server and configure all the roles and migrated all Mailbox, public folder etc. to new server successfully.

Installed one new DC (Windows 2008) and configured this DC as GC replicated DNS. All seems working fine on new DC as expected.

Now real fun is going to start. If you see various blog post and TechNet forum discussion, lots of MVP and expert advice to use CMDLET “Set-ExchangeServer” and point new DC/GC as static. I agree its good cmdlet and help Exchange Administrator to avoid any down time while you ask exchange to talk with new DC/GC

BUT, What about if someone change DC/GC for whatever reason – it becomes unavailable for an extended period of time (or worse: someone decided to decommission the server without telling you (happens all the time!). This would cause the Exchange Server to try binding to a non-existing DC/GC. Again if you want to remove static entry you can’t do as EMS is not getting started.

To avoid such issue and let exchange connect itself new DC/GC you need to allowing exchange minimum 30-45 minutes time. In this duration lots of event will generated as below.

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1111).
Exchange Active Directory Provider will discover the new DC’s and will show in in event log (Event id : 2080) . Let concentrate the event now.

(Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)
In-site:
DC-OLD.ABC.local CDG 1 7 7 1 0 1 1 7 1
DC01.ABC.local CDG 1 7 7 1 0 1 1 7 1

If you see above the SACL value of both DC is ‘1’ which indicates that both DC’s are working as GC’s now. Now it’s time to shutdown/Disconnect old DC from network. Wait for 30 minutes and observe event logs. Go exchange server and try to restart Exchange AD topology server which would stop all services one by one and then start it again. Once all service are started , now you can confirm that new exchange is talking with new DC.

Now wait for couple of days and proceed with exchange & DC/GC removal.

Note : in some cases it has been observers that SACL value is  not showing 1 for new DC which cause exchnage to down. To resolve this. In the Default Domain Controller policy AND the Default Domain Policy under Windows Settings –> Security Settings –> Local Policies –> User Rights Assignment, the policy “Manage auditing and security log” must have the Exchange Servers group added. This was not added in this environment. Once this was added the SACL as above changed to “1″ and the Exchange services started correctly

So, Why Set-exchangeServer cmdlet 🙂