Well, if anyone is interested, I solved this problem 2 different ways. Let me just preface this with one detail. The server I was having the issue on was secured in such a way that I did not have access to it properly (ie. no RDP, shares were secured so I couldn't drill down).

(Spoiler alert... Method 2 was much easier).

Both methods were done AFTER taking a fresh backup, of course.

Method 1

After asking the SQL community, researching and seeing answers to other questions that if there is a DBCC error prepare to repair the data from backups and logs or a new structure if no good backups exist, I got started. I had to go the new structure route since I did not have a good backup (knowingly) since the condition existed before I started at my new job a couple months ago. After asking a couple of other well known SQL gurus out there, I got the reply to look at getting a Microsoft ticket started. Trying to avoid $$ signs was looking unlikely.

So I scripted the entire database structure (which thankfully was not overly large on tables) and created a new database, leaving the existing one intact. Then I imported the data from the existing database into the new one, 1 table at a time (with the expectation of having an error).

Thankfully no errors occurred while importing (which was interesting) and once all was done, and DBCC done again.... no more errors!!

Intermission

So, I took the task to another server, where I had more access. For this server, I could RDP to it, see all drive and directory information. While just looking at the problem database on this server, I noticed this (see attachment for actual screenshot).

NameSizeTypeDate Modified

$FSLOGFile Folder9/28/2014

5f1b7b51-5168...File Folder5/8/2012

f475d0a5-4b9d...File Folder5/8/2012

[highlight]temp[/highlight]File Folder11/29/2012

filestream.hdr1 KBHDR File9/28/2014

Apparently this temp folder was created in the filestream repository nearly 2 years ago. However, what it did for me was allow me to actually see the folder name "temp" matching my original error from DBCC. With this new information, I went back to my network system admins to have them look at the file space on the server I'd just fixed. Sure enough, no "temp" directory there.

So I knew I had a solution (Method 1) but what if, just perhaps, the answer was simpler. Of course done when no one was in the database.

Method 2

Navigate to the directory containing the Filestream. Expanding into the filestream I could see the "temp" folder and the fact that it was empty. Click on "temp" and delete. Fast, simple, done.

Reran DBCC just as before and voila.... "Command(s) completed successfully."

Summary

Apparently someone, not knowing what the filestream folder/object was, created a "temp" folder in it on that fateful day some nearly 2 years ago. No knowledge of why as any involved left before I took this new job. However, I am suggesting that if you run into this error and you have a recently taken backup, it's possible this might fix your error, if you're lucky enough to run into this as your only DBCC issue.

Hope that was thorough enough.