Windows automatic update for Win10 install - kills BR

[GomezL]

Couple of things to try

* Setup a very simple wbconfig.sys, sometimes the config problems are subtle, and not what they look like at first.
* Try using a UNC Path
DRIVE L:,L:,L:,\BR becomes L:,\\server\share,L:,\BR
* Be Specific about the WBSERVER -
WBServer \\server\share\BR
* Try coping BR to the C:, but using the L: Drive statement, make sure the WBSERVER is configured. This can sometimes resolve some network problems.
* Make sure they have "Lots of Rights", start with Administrator, and then scale back if that works.

Another things worth noting, client server really makes a difference. At this point, it's very stable, and the performance advantages are huge. Now that we have migrated, corruption due to network issues are virtually gone.

[mluchterhand]

Susan,

If you still think the issue may be related to something Microsoft is pushing out you might be able to narrow it down by cleaning up system files. Right click on the Operating System drive, go to Properties, then click Disk Cleanup. Then go to Clean Up System Files. One of the checkboxes will be quite large but I can't remember what it is called. That is where Windows 10 installer files go. You could see if deleting those files resolves the issue and maybe narrow it down.

[Susan Smith]

Thanks Luis and Matt!

Matt: I will pass this on to Gary. He is also installing GWX Control Panel, an application that blocks the Win10 stuff.

Luis: I will try your suggestion. But to follow up on one of your suggestions (since you need to tell me things as if I am a second grader),

When you say "Run BR on drive C:", would I copy all of the "config" type files to the C: drive as well or just the BR executable?
Or does it matter? (Obviously, if I copy BRCONFIG.SYS or PRINTER.SYS or any others to the C: drive, my BR call and INCLUDE statements would have to find them there. I get that part.

So either
C:\BR\BR.EXE -C:\BR\BRCONFIG.SYS
or
C:\BR\BR.EXE -\\FILESERVER\SHARENAME\BRCONFIG.SYS

-- Susan

[GomezL]

In my application, I have a folder called WBWIN that has all of the BR Components

BR.exe
wbconfig.sys + includes
startup.bmp
dll files
etc.

My suggestion was to copy everything, although you can probably copy just some to try.

---

I was also interested in your idea:

Copy to C:\BR

• br.exe
  brclientdll431hd-Win32-Release-gui.dll
  brserial.43
  startup.bmp

Then start BR
C:\BR\BR.EXE -\\FILESERVER\SHARENAME\BRCONFIG.SYS

This worked very nicely for my application.

[Susan Smith]

Thanks Luis! We're going to test your ideas, one at a time.

First, using the UNC Name for the path. That seems the easiest, but it requires everybody

If that doesn't work, I'll copy stuff to the C: drive

I appreciate the help. This problem has really come out of the blue, and the only recent variables (that we know of) are these blasted Windows patch pushes for "Preparing your computer for a seamless transition to Win10" (whether you like it or not, I will add). If we restore the computer, the BR problem goes away. But the patches are re-pushed every single day, even after hiding them from Windows Update (MS changes the hidden status so they show up again). We're working on that aspect of things as well. But at least, I might be able to work around it all by changing BR calls.

I'll let you all know how it is resolved.

-- Susan

[Susan Smith]

Hi guys,

Well, I'm not anywhere yet.

We have tried a few things:

1. Changed the desktop shortcut and config.sys files to use the UNC names. It worked fine for ME when I log in via Remote Desktop. (The old way with the mapped drive letter worked fine for me too.) But this one local workstation (the boss's) STILL cannot get into BR.

2. We changed the sharename because it had spaces in it and you never know if some weird MS patch got pickier about that - even with quotes. That didn't make a difference.

3. I can't copy the BR start files to C:\BR because we mount backup flash drives there and run from there automatically. But I can try putting it somewhere else locally, like C:\BR_PITA

The other thing that Gary is trying is something to do with SMB2 and SMB3. Something in Steve's message jogged an idea that he is following up on.

But for now, I have to get back to a different fire. So I'll let you know what we try next.

Thanks so much for the help.

-- Susan

[Susan Smith]

Woo hoo! It's fixed!

First of all, thanks to Luis who helped me narrow it down to the point where I could figure it out. Luis, I took your advice and tried to run BR from the C: drive and then point to the network share after BR was connected. That worked! Yet, I could see the network share (with BR) via Windows Explorer and by popping down into the CMD line and doing an old-fashioned DIR. So I know that the drive was mapped correctly on the workstations.

Next I started cutting pieces out of my config files and determined that as I suspected, it died on the Drive statement, but depending upon what I screwed around with, sometimes I would get an error regarding the WBSERVER.DAT file. That gave me the final clue.

I asked the systems/network guy to check the permissions for the BR folder (I don't have authority to do that on their system). It looked good. Every user is part of the "Everyone" group and the Everyone group has full rights to the BR folder. But he refreshed the permissions and then it worked! I know they were having trouble with Windows patches, so it's possible that this could have been a cause of the permissions getting knocked out. But I don't know. The permissions were made for the "everyone" group. The people who couldn't get in were still listed in the group, but they weren't inheriting the permissions for some reason. After refreshing the permissions and pulling those people out of the Everyone group and putting them back in, It seems to be be working! We may never know what actually caused the permissions issue, but in the end, it had nothing to do with BR or my applications. No modifications of any kind ended up being required on my side of things whatsoever.

David had a good suggestion: don't depend on any built-in server "groups" from Microsoft to issue permissions. If MS creates them, they can mess with them. So we should create our own version of an "everyone" group and give permissions there instead. Good advice.

Thank you all so much!

And while I'm at it, there is a link available now from the Drury Plaza to book your hotel rooms for the May 19-21, 2016 Business Rules Conference. I'll go post it in the Conferences section in a bit.

-- Susan

[GomezL]

Glad it worked out!

From your description, I would make sure that the SMB patches mentioned above are implemented.