Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

BCM400 R3.7 "BRU was not able to remove the mapped drive Z:"

Status
Not open for further replies.

ForeverBlue

Programmer
Sep 10, 2018
5
US
We have a Rel 3.7 BCM400 that is refusing to backup. Within BRU, after selecting the appropriate backup location (same one that works fine for other BCMs in the same network) and specifying a time to backup (doesn't matter if Now or Scheduled), when you click on START BACKUP, you get a message box saying "BRU was not able to remove the mapped drive Z:". When you click on that box, you get another one saying "The BACKUP has been canceled by user". It appears that sometime in the past, someone has mapped a network fileshare that isn't wanting to go away.

I've tried several things from the DOS command prompt:

NET USE Z: /DELETE comes back without error, but the backup still fails.

NET USE shows no mapped drives.

A DIR of a normal unused drive letter shows 'The system cannot find the path specified.', but a DIR Z: shows 'Logon failure: unknown user name or bad password.', indicating some association with a network fileshare.

Another post in a different forum indicated success in a situation like this when using the form NET USE {UNC} /DELETE (e.g. NET USE \\server\share /DELETE), but we have recently took up maintenance on this system and have no history of the previous UNC, and I don't know of any way to print it out.

Ideas??
 
I've tried several things from the DOS command prompt:"

on what? your server or BCM?

Have you tried Maintenance Tools?

________________________________________
small-logo-sig.png


=----(((((((((()----=
Toronto, Canada

Add me to LinkedIN
 
Sorry, I forgot to put that in the post. The first place I went was to Maintenance Tools. In that menu I went to Detach Shared Volume, entered Z:, and clicked Execute. It returns:

[tt]2250
Disconnect Z:
2250 : This network connection does not exist.[/tt]

BRU still shows the same problem afterwards.


The DOS commands I mentioned were executed from the DOS command line of the BCM exhibiting the problem, accessed via telnet and the menu option '7. Command line'. The full output of the commands is below:

[tt][BCM200_M]C:\TEMP>net use z: /delete
The network connection could not be found.

More help is available by typing NET HELPMSG 2250.


[BCM200_M]C:\TEMP>net use
New connections will be remembered.

There are no entries in the list.


[BCM200_M]C:\TEMP>>dir m:
The system cannot find the path specified.

[BCM200_M]C:\TEMP>dir z:
Logon failure: unknown user name or bad password.

[BCM200_M]C:\TEMP>[/tt]

Also, I forgot this was one of the few BCM200s in their network and not a 400, but I don't see that being relevant to the problem here.
 
When was the last time the BCM was rebooted?. I recall the older Windows NT versions being very strange with odd bugs and a reboot usually fixed it.

Also what was the current patch status?

I think the final release for 3.7 was..

BCM 3.7
==================================

PATCH ID: BCM370.200-BIOS Category: GEN done
PATCH ID: BCM00168 Category: GEN don't have the patch!
PATCH ID: BCM370.243-BRU Category: GEN done
PATCH ID: BCM370.252-RCC Category: GEN done
PATCH ID: BCM370.256-OS4 Category: GEN n/a
PATCH ID: BCM370.209-MSCSVC Category: GEN done
PATCH ID: BCM370.213-SU3 Category: GEN done
PATCH ID: BCM370.250-DSPFW Category: GEN n/a
PATCH ID: BCM370.215-VP5 Category: GEN n/a North America Day light saving hours
PATCH ID: BCM370.222-VP3 Category: LTD n/a Western Australia Day light saving hours
PATCH ID: BCM370.240-VP6 Category: LTD n/a New Zealand patch
PATCH ID: BCM370.255-VP7 Category: LTD n/a Australian Day light saving hours
PATCH ID: BCM370.194-OS2 Category: GEN done (increases disk space on the F drive)
PATCH ID: BCM370.204-CP Category: GEN done
PATCH ID: BCM370.226-VM Category: GEN unable to install
PATCH ID: PreCheck_Tool Category: GEN
PATCH ID: BCM370.237-UM3 Category: GEN done
PATCH ID: BCM370.245-UTPS-SRG Category: GEN unable to install
PATCH ID: BCM370.248-FEPS Category: GEN done
PATCH ID: BCM370.212-QOS Category: GEN done
PATCH ID: BCM370.227-WANDVR Category: GEN n/a
PATCH ID: Patch_Wizard2.5 Category: GEN
PATCH ID: BCM370.249-CORE Category: GEN done



Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website = linkedin
 
Last reboot date is unknown. All the customer could say was "it's been a while". Apparently they had a bad experience with a system restore from their previous vendor and they're touchy about doing anything to that site. I'm not aware of any way to determine last boot time from the logs. I poked through the system logs and found "CALLPILOT BOOTED" entries in the STLOG.OUT file, but CallPilot gets rebooted every time a backup occurs, so that's not a very good indicator. Do you know of a better one?

Your list matches my archive with respect to 'last and final' BCM 3.7 patches. This BCM looks to be behind, though. The patch status on the problem child is:

Patch Name Date Applied
BCM_370.213_SU.99.3 02/13/2007 1:33p
BCM_370.033_VP.41.001 02/13/2007 1:33p
BCM_370.039_SECURITY.00.896422 02/13/2007 1:33p
BCM_370.040_MSM.26.202 02/13/2007 1:33p
BCM_370.041_MSCSVC.20.372100 02/13/2007 1:33p
BCM_370.060_WANDVR.17.241 02/13/2007 1:33p
BCM_370.061_WIN.00.899588 02/13/2007 1:33p
BCM_370.062_NRU.16.1001 02/13/2007 1:33p
BCM_370.080_MPS.34.003 02/13/2007 1:33p
BCM_370.094_CDR.64.151 02/13/2007 1:33p
BCM_370.097_ALRMMON.46.11 02/13/2007 1:33p
BCM_370.114_QOS.70.3709 02/13/2007 1:33p
BCM_370.116_IPSEC.71.3707 02/13/2007 1:33p
BCM_370.127_BRU.10.020 02/13/2007 1:33p
BCM_370.130_IPVSB.62.012 02/13/2007 1:33p
BCM_370.132_SETFW.56.161 02/13/2007 1:33p
BCM_370.139_HGMR.148.240 02/13/2007 1:33p
BCM_370.148_OS.00.001 02/13/2007 1:33p
BCM_370.151_SIPUA.67.361100 02/13/2007 1:33p
BCM_370.155_PCM.43.129 02/13/2007 1:33p
BCM_370.157_CTE.40.251 02/13/2007 1:33p
BCM_370.158_CPISB.22.2500628 02/13/2007 1:33p
BCM_370.159_WIN.00.911280 02/13/2007 1:33p
BCM_370.161_UM3.39.002 02/13/2007 1:33p
BCM_370.166_DSPFW.09.5134 02/13/2007 1:33p
BCM_370.169_DP.57.017 02/13/2007 1:33p
BCM_370.171_WIN.00.917159 02/13/2007 1:33p
BCM_370.174_CP.22.2500629 02/13/2007 1:33p
BCM_370.175_FEPS.33.372200 02/13/2007 1:33p
BCM_370.179_WIN.00.921883 02/13/2007 1:33p
BCM_370.183_CORE.08.0714 02/13/2007 1:33p
BCM_370.184_IVR.02.3509 02/13/2007 1:33p
BCM_370.189_UTPS.12.17180 02/13/2007 1:33p
BCM_370.191_RCC.61.344 02/13/2007 1:33p
BCM_370.192_VM.22.0109 02/13/2007 1:33p
BCM_370.197_SRG.51.1103 02/13/2007 1:33p
BCM_370.201_CTI.01.370141 02/13/2007 1:33p
BCM_370.203_VP2.41.0303 02/13/2007 1:33p

Patching will probably be the last option though they want to try though, given their past experience at this site.

While looking through the logs via Maintenance Tools, I did notice that the first time I attempted to do a backup was partially successful, and there's a .log file in the /logsFolder/BRU/Scheduled folder, even though no logs or reports show up in BRU for that backup attempt.

I also noticed from the .log file that BRU uses Z: as the drive letter when backing up to a network file share, and that it backups to to E: first, then does a COPY from E: to Z:.

I'm wondering if BRU is what's causing Z: to be stuck, and if (at least to get a successful backup) I could backup to E:, and then manually move the file off of the BCM and onto the backup file share... I'll try that later and report back.
 
There is no easy solution to your problem. My initial thoughts are the hard disk and are you able to find out the manufacturer as it will probably be the troublesome Maxtor that were originally fitted.

The later Seagate ones were much better. it's not uncommon for disk space to become limited due to ever increasing log files. I once had to go in via the serial port and delete hundreds of CDR files prior to doing an upgrade to 4.0.

Usually if the hard disk fails, the BCM only runs in TDM mode and no IP will function. One test that you could try that shouldn't be service affecting is to run the 4.0 upgrade tool as this will examine the system and disk for any errors.

I have attached a copy.

Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website = linkedin
 
"There is no easy solution to your problem."

I fear you are correct...

I'm well familiar with the signs of a failed BCM HDD. Flashy flashy LEDs and no IP or CallPilot top the list. I think in this case though, I may have a failing HDD, not a failed one. Here's what I've found since the last post:

I went in D: via telnet to delete the CDR files just as a matter of course and to make the backup quicker once it did start. I did a DIR in the Call Detail Recording directory, and the command prompt just hung. At first I thought there may be a really huge number of files, so I killed the telnet session, logged back in, and did a DEL *.* without doing the DIR first. I know it started to delete files because it came back and said (like usual) that it couldn't delete the file that was in use for this day. However, after that message, it hung again. I let it sit for at least 30-45 minutes, and it never came back to a prompt. I can DIR other directories in D:, but just not that one. I think it's corrupt.

After that, I started up BRU again and this time selected E: as target, selecting only telephony to back up. After entering the report name, I get a message saying "THE DRIVE IS NOT READY. PLEASE VERIFY IT" and it cycles back to entering a report name. It doesn't say which drive, but I assume D:.

The web interface and the VoIP trunks work fine, and I can navigate everywhere except that particular folder, so that makes me think the HDD is either corrupt or starting to fail, but definitely not completely dead. I could try rebooting or maybe CHKDSK D: /F, but fear those could be potentially risky, so I'm thinking I may just leave it as-is. We have a good backup from 2016 and this is a small site that may be replaced soon, so getting a backup is 'a good thing', but not necessarily something I have to do. I'm still open to other thoughts though...
 
Squirrely Windows problems like this is probably why the BCM was switched to Linux at R4. I still use Windows 7 (Ultimate) on my PC's and networking usually works OK. But from time to time one or more PC's can't find a mapped network drive for no good reason and a reboot usually brings it back. Networking was never Microsoft's strong suit. Replacement hard drives are available on eBay if you decide to go that route.

Brian Cox
Georgia Telephone
 
Agreed on all points. I haven't used Microsoft networking much over the years, but have heard your comment before. I'm still on Win7 on all my systems too. Windows 10 is too 'chatty' with Microsoft for my tastes, and I refuse to move to it until I'm forced to (i.e. when they stop putting out security patches for Win7). Plus, there are certain Nortel applications that won't run on Win10, which makes it an immediate non-starter for me.

Appreciate the pointer on the ebay option, but no need here as yesterday I was making up BCM drives for our own stock.

I broke the news to the customer and they're fine with putting this site on the top of the list for us to replace with a UCx. They were already going down that road anyway.

Thanks all!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top