greystone_gmi
asked on
ESEUTIL -1022 (JET_errDiskIO) error
I am attempting to do a defrag on my ISPRIV in exchange 5.5 SP4 running on W2K SP3. I do not have enough space on the exchange server so I have mapped a drive to another server to store the temporary database. When I do this I get the -1022 (JET_errDiskIO) error occured at such and such a time. I also got this same error when I ran this on the Directory. Fortunately I have enough space on the drive to defrag the directory locally and I did not receive this error. The only time this error occurs is if I point the database to a mapped drive.
I have checked various MS articles and ran a CHKDSK on the drives and it didn't come up with any errors. We have successfully done this in the past, I am not sure why this would be happening now.
We are also running Mcafee VirusScan Enterprise 8.0i on these servers and I shut the services off while doing the defrag an d this did not make a difference.
Any help would be appreciated
I have checked various MS articles and ran a CHKDSK on the drives and it didn't come up with any errors. We have successfully done this in the past, I am not sure why this would be happening now.
We are also running Mcafee VirusScan Enterprise 8.0i on these servers and I shut the services off while doing the defrag an d this did not make a difference.
Any help would be appreciated
Make sure you allow unc paths in the DOS prompt. There is a registry edit. http://www.winguides.com/registry/display.php/1247/
Remember to surround your path with quotes if they use spaces.
Remember to surround your path with quotes if they use spaces.
...and you did mitigate one of the errors of a -1022 on a defrag - killing AV
ASKER
Thanks I will check our network switches to ensure that we aren't getting collisions and that the ports are detecting the proper speeds of the Nic's in each of the servers.
As for the UNC Registry change I have mapped the drive to a K:\ drive, would that UNC reg key still need to be in place?
As for the UNC Registry change I have mapped the drive to a K:\ drive, would that UNC reg key still need to be in place?
to the best of my knowledge, no
ASKER
I checked out our switches and we aren't seeing any collisions and they are detecting the servers as 100Mb/s full duplex. I also did a ping between the two servers and a regular ping returns a result of <10ms and the same occurs if I do a ping of 1500bytes.
greystone - What you are trying to do should work (and has worked for you in the past). With a 100/F network and very little traffic you should have no problems running this. Why you can't run it over the wire, with a mapped drive as your temporary drive, is now beyond me. Have you tried a different drive letter? (I am going to say that this should not change it at all.)
One question...is the K drive a direct mapping (I am assuming you are mapping to an empty share or an empty hidden share)? Are there any spaces? Does the other server, the system account, the account doing the defrag, etc. have NTFS access? If you set Everyone to Full on the share and Everyone Full onto the directory's NTFS permissions , is there a change?
One question...is the K drive a direct mapping (I am assuming you are mapping to an empty share or an empty hidden share)? Are there any spaces? Does the other server, the system account, the account doing the defrag, etc. have NTFS access? If you set Everyone to Full on the share and Everyone Full onto the directory's NTFS permissions , is there a change?
ASKER
I'm using our domain admins account to map the drive to k: wich is mapped to \\servername\d$ . This domain admins account has full admin rights to the server that the share resides on as well as full control on the share itself.
Create a folder subordinate of d$, give that directory Everyone full (or at least Administrators Full, System Full, ExchangeServiceAccount Full). Share out the directory, map a drive to it, and see if you can test it and see if it works.
ASKER
Thanks for all the help...I will setup a folder as you have indicated and try it again.
ASKER
I should add that the temp database file gets written to the shared drive and fails at different points each time.
Oh...then that is different.
That is odd if it fails at different parts each time.
Try setting the NIC and the switch port to 100/Full.
Our of curiosity, do you defrag often (hopefully not) or are you in the middle of a migration attempting to recover disk space so that backups don't run too long on the server being replaced.
Bob
That is odd if it fails at different parts each time.
Try setting the NIC and the switch port to 100/Full.
Our of curiosity, do you defrag often (hopefully not) or are you in the middle of a migration attempting to recover disk space so that backups don't run too long on the server being replaced.
Bob
Here is another method (assuming you have enough space on the remote machine):
Note: You need 110% of the database size in availiable free space.
1. COPY the database to be defraged to the remote machine. Create a directory for it.
2. COPY the ESE.DLL and ESEUTIL.EXE into this same folder on the remote machine.
3. Go to the remote machine and open a command prompt.
4. Change directory to the folder where the files above reside. Run the following command:
ESEUTIL /D <database name>
Example:
ESEUTIL /D PRIV.EDB
Note: Don't use /ISPRIV with this method.
5. After the defrag completes, copy it back to the Exchange server. You should have a copy of the original file backed up just in case.
Hope this helps.
Note: You need 110% of the database size in availiable free space.
1. COPY the database to be defraged to the remote machine. Create a directory for it.
2. COPY the ESE.DLL and ESEUTIL.EXE into this same folder on the remote machine.
3. Go to the remote machine and open a command prompt.
4. Change directory to the folder where the files above reside. Run the following command:
ESEUTIL /D <database name>
Example:
ESEUTIL /D PRIV.EDB
Note: Don't use /ISPRIV with this method.
5. After the defrag completes, copy it back to the Exchange server. You should have a copy of the original file backed up just in case.
Hope this helps.
ASKER
I figured out part of the solution....I tried forcing 100Mbps full duplex on both the NIC's and the switch ports and this still did not work. I also tried copying the database but our is 42GB and after 10 hours it hadn't copied even a quarter of the file across.
So to do some eliminating I used a crossover cable between the two servers and this worked fine. I didn't see any errors on the switch so I am not sure why this didn't work with it connected to the network. I'm guessing that there is still a problem with my switch configuration.
In any case I was able to defrag the database.
Thanks for all everyones suggestions.
So to do some eliminating I used a crossover cable between the two servers and this worked fine. I didn't see any errors on the switch so I am not sure why this didn't work with it connected to the network. I'm guessing that there is still a problem with my switch configuration.
In any case I was able to defrag the database.
Thanks for all everyones suggestions.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The standard seek times are around 8ms for IDE and 3ms for SCSI, if memory serves me correctly. A network should not add more than a few ms to that time. A slow network may not have the throughput for it to run...but I haven't ever seen that become a problem outside of taking too long to run.
So, it may be that network latency and link speed are causing it to flub...
Bob