Friday, December 5, 2014

.NET WSDL integration array error

I have not had a lot of need for web services over the years, but now and then they have come in handy, so I have had to learn about them; including some of the hair pulling issues that they can result in.

For this post I was trying to integrate a C#.NET solution with  A few years ago I had done the same thing using the older Web References which I was more familiar with and which were less flexible and therefore simpler to use.  However this time I had a bigger development window and decided to do things right using the newer Service Reference.

Most of the changes were not too hard, just took some digging since so much of the Sales Force documentation uses the old web references code.  Add to that the fact that Sales Force had made some decent sized changes to their WSDL over the years and it took me a full day to get the code to compile the first time.

When I ran it for the first time I received this odd error :

Error CS0030: Cannot convert type 'TRCWebApp.SalesForceEnterprise.ListViewRecordColumn[]' to 'TRCWebApp.SalesForceEnterprise.ListViewRecordColumn'

The most confusing part initially was that I didn't recognize the class from the basic login code I had written, I had never used it.  Fortunately, I was not the first person to run into this problem, and I was able to easily find the solution here.  What bothered me enough to write this post is that it was not an error in my code, or even in the Sales Force WSDL.  It was actually an error in the .net code generator that created the Reference.cs class from the WSDL.

Apparently the "code generation component cannot handle the XSD definitions that have only one element and the occurrence of the element is unbounded."

There are two solutions listed that I found:
1. "to manually modify the schema and altered the constructors for those 2 classes mentioned above by adding an extra dummy attribute".  The Sales Force specific fix is shown here, of course you would have to regenerate the code after making the change:

2. The option I chose was quite a bit simpler as long as you know where to find the generated Reference.cs file in the Service References folder of your project.  "I had to delete the extra [] from public ListViewRecordColumn[][] records in Reference.cs which is a file that is formed from the WSDL".  I opened the References.cs file in Notepad++ to follow those directions, did a search for ListViewRecordColumn[][] and renamed all two instances of it to ListViewRecordColumn[].

Problem solved, my code compiled and was able to talk to Sales Force.

Thursday, November 13, 2014

.js normal reference to embedded file authentication issue in .net

I had written a fairly complex paging object in javascript for a custom reporting system built on the .net platform.  It was all bundled up as an embedded resource for the custom system but I wanted to re-use it for another part of the site that suddenly needed to do paging.

When I first added the file reference in the head of my HTML document everything was working great.  But an hour or so later I started getting javascript reference errors saying there was a syntax issue inside the file.  I looked at what my browser was referencing as the file and discovered that it was getting an authentication denied page instead.

It turns out that .net handles embedded resources a little differently than normal files; which is to be expected since they get bundled up in the dll.  I was just expecting a second copy of my .js file to remain in its folder in addition to getting bundled, but it would seem that .net protects that file.

I was able to get my basic reference working correctly by navigating to the reporting pages which reference the embedded resource.  Once the reporting system had correctly authenticated and downloaded the embedded .js file then my other page was able to use it until that authentication ran out.  The long term fix of course it to add an embedded reference to the file on the new page as well.

Monday, September 8, 2014

Custom Security System

If you are considering setting up and installing a personal security system by yourself, the amount of setup involved can be daunting.  Even if you do have the technical know how to get the wires plugged in correctly, the base station installed, scheduled, and connected to the internet properly; you still have to deal with the headache of actually running the wires and the ability to overcome wire length limitations.

Do-It-Yourself Option
Fortunately technology has come a long ways, and it is now possible to purchase a nice do-it-yourself home system for fairly cheap.  Several companies have come out with IP based cameras which can connect to your existing computer network making setup costs much lower.  However, unless you get the cameras on sale, they will end up costing as much as a traditional system.  The brand I have gone with is D-Link.  The D-Link DCS-930L and DCS-932L cameras are great; the 932 has night vision while the 930 model does not.  When on sale you can get the DCS-930L for as low as $30 from, and the DCS-932L for as low as $40.

The two reasons I chose the method I did for a personal security system are: it is easily implemented on top of my existing IP based network, and two it is very scalable.  So I can slowly buy one camera at a time and increase my system as desired, needed, or money is available.

There are of course other security devices such as the magnetic open window detectors, but most security firms have long since stopped using those due to the inherent flaw that you can just break the window and they won't go off.  Motion detection, night vision, heat sensing, and image capture seem to be the key features common to most modern systems.

Considering the price, these cameras have a wide range of abilities.  Everything from emailing on motion detection, to built-in remote viewing over the Internet.  Of course you can also schedule the activation of night vision or motion detection as well as choose where in the viewing area motion will be checked for and at what sensitivity level.

The biggest downside to this system is the resolution, or picture quality.  While it works great in a normal house or office building, it is not good enough for facial recognition at long distances.

Convenience and Security Risks
The cameras do have an incredibly convenient wireless feature which allows you to setup the security network with almost no effort so long as you are within range of a wireless router.  Using this method does put your system at risk for an interference attack.  Even something as innocent as a microwave can take down a cameras wireless signal if it is close enough.  However, the chances of a normal residential house being broken into by someone with enough knowledge and skill to take advantage of that seems unlikely.  And for businesses who need to be more careful the camera does come with a standard ethernet jack.

These cameras do require power in order to function.  Which means that a backup generator, or battery backups would be required to overcome an attack where someone cuts the power to the location.

Most of this does require an active Internet connection to work as well, which of course is another potential security flaw should an intruder cut your Internet access.  While a redundant Internet connection would be nice, most people building their own system do not want to spring for such an expensive recurring cost.

Fortunately D-Link gives away for free a very nice software package called D-ViewCam which brings the power of a traditional base station to this custom system.  It allows for video recording on schedule, motion detection, or manually.  It provides remote access to both the cameras and archived recordings, and has extensive logs built-in so you know about any network related issues or user actions that have affected your system.
EDIT: I have since moved to Mileston's XProtect Pro system, an amazing product.

Alternate Options
D-Link is not the only option out there, it just happens to be my favorite.  Brands such as Wansview offer cheaper cameras than D-Link, but reviews indicate they may not last as long and the management software does not feel as polished as the D-Link offerings.

If you are comfortable with running wires you could go the route of an ELEC system, which are incredibly inexpensive for what you get.  Less convenience, more functionality.  The ELEC brand is currently the cheapest closed circuit I am aware of; obviously cheapness carries all the normal risks of cheap hardware and software.

So far I have had very little success combining more than one brand for the near free price I like.  None of the brands software supports other brands hardware.  However there are a few third party options that give something in this area. Blue Iris seems to be a common favorite among the industry, but the interface was not clean enough for me to be interested in the learning curve, and it is not free.  iSpy was my favorite, it has a bit more polish and supports anything and everything I could possibly want.  Unfortunately iSpy does not have a reasonable remote or mobile offering, the best I could come up with for a mobile app to supplement iSpy is called IP Cam Viewer Lite.  It was able to successfully connect to both my D-Link IP cameras, and my ELEC CCTV system; the downside was I had to give up a lot of the custom and extra functionality the brands own apps gave.  It was a great mobile viewer that rivaled and sometimes surpassed the brands personal software's viewing capabilities, but not much more.

In conclusion, if your building requires the additional security of being up through a power failure, and being less susceptible to other types of direct security system compromises, I would recommend going with the more traditional closed circuit systems.  However, if you are looking for something quick that will cover 90% of every day events with minimal hassle, setup, or costs, then the system I have built is probably exactly what you are looking for.

Saturday, May 17, 2014

Windows IP Configuration and nothing else

I recently had the need to clean up a friends computer that had been completely trashed by every form of bad computer use habits you can think of.  It had ad popup software, multiple virus scanners stepping on each other, more browser toolbars than I could count, along with logs of other pointless software.

Uninstalling the extra software wasn't all that difficult, just took a little patience.  However, some of the software corrupted the network adapters so badly that they were unable to actually connect to anything even though they claimed to be connect.

running ipconfig would only return "Windows IP Configuration" and nothing else, no data was being returned.  ipconfig /all would still not return any adapter information, but it did say:
IP Routing Enabling : No
WINS Proxy Enabled : No

I thought that was the problem, until I looked on one of my other computers and realised the settings were the same.

Poring over the internet gave me lots of solutions to try.  From an elevated command prompt I ran:
netsh winsock reset catalog
netsh int ip reset reset.log
netsh int ipv4 reset reset.log
netsh int ipv6 reset reset.log
Some combination of those had fixed 90% of issues people on the internet had.  However, they had no affect on my issue.  I also tried playing around with some registry settings that some of the more desperate people had claimed worked for some of their issues.  These two settings required a machine reboot after and were supposed to enable the ip routing and wins proxy.  The ip routing one worked, but the other kept getting reset after a reboot.  However, neither fixed my core issue of an active network connection that could pass data.
set EnableProxy to 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\Tcpip\Parameters\
set IPEnableRouter to 1

I finally found an odd sequence that worked for me from this discussion thread:
1. disabled the network adapter
2. open up the network adapter and unchecked all network items/bindings in the adapter
3. ran repair on the adapter (it will ask for admin permissions which I gave it, it will re-enable the adapter and claim it did other repairs)
After doing that simple, yet odd, sequence my network connection was fully restored.

Monday, May 12, 2014

Network testing with iperf

I have had a couple of occasions now to use the iperf utility in network testing and have come to love it enough that I decided it warranted a post.  While there are more powerful tools such as wireshark, this one is nice because it is so lightweight.

The first time I used it was to test the bandwidth capabilities of my switches.  I discovered that my standard computers were unable to generate enough data fast enough to put a load on a gigabit switch.  By starting up a server to consume the data I was able to start up multiple clients feeding it to get me pretty close to the limit.
# starts the server in listening mode
(server): iperf -s
#runes the client for 1200 seconds which is 1 hr to the servers ip
(client): iperf.exe -c -t 1200

The second time I needed this handy utility was when troubleshooting a voip phone network.  I was not getting any dropped packets from the ping tests I had done, so I turned to this utility to see if perhaps UDP packets were having issues.

-c is client ip, -b is bandwidth size to be tested which adjusts how large of packets are being sent., -t is the number of seconds to run the test for.
(client): iperf -c -b .5mb -t 180
-s initiates the instance as a listening server, -u specifies it will be a UDP test, -i specifies the reporting interval in seconds.
(server): iperf -s -u -i 1

Wednesday, April 16, 2014

Spiceworks Migration: an existing connection was forcibly closed by the remote host

I recently had to migrate my Spiceworks install from a Windows XP machine to a Windows 2012 server.  There was nothing wrong with the Windows XP machine, other than XP being end of life.  We simply needed faster hardware as we were planning on using the new help desk system built into it; prior we were just using it as a network scanning and monitoring solution.

I had tested the Active Directory integration on the Windows XP machine and had it all working nicely.  Unfortunately when I brought it online on the Windows 2012 server, Active Directory users were no longer able to login.

After looking through a lot of posts I checked out the AD scanning settings and noticed that I was getting the error: "an existing connection was forcibly closed by the remote host" regardless of the user account I tried to log in as.  In fact, after some more playing, I noticed that none of the credentials I was trying were even saving to the system, perhaps it only saves if there is no error.  However, I did get a different error if I changed the name of the domain controller, and in the domain controllers security log I was able to see successful authentication attempts.

I was quite confused, I tried all sorts of suggestions and even verified that LDAP was working correctly using the ldp tool as one post suggested.  I tried looking through the logs but could find no no mention of keywords "LdapAD" or any of the other keywords that other people had mentioned finding.

Finally I ran across a post where the user solved their problem by changing the LDAP port to 3269.  That got me thinking, I had the same issue when I was first trying to set mine up and I had set mine to 3269 at that time as well to resolve the issue.  I tried removing that setting, and suddenly everything worked.  The only thing I can think of is that the port it likes is different between the WinXP machine I came from and the Win2012 machine I am now running on.  Since the AD machine never change it does not makes sense to me, but it works.

Thursday, February 6, 2014

Installing Sharepoint 2010

The Problem
It took me far longer than I care to admit to figure out how to successfully install Sharepoint 2010. I spent hours searching Google, giving up, trying stuff on my own, and going back to Google.  My major symptom was a "successful" install but the web administrative interface was simply a white screen, no errors, absolutely nothing.

I tried everything I could think of, including creating my own tested and working website and copying over the sharepoint files into it.  But the best I could ever do was generate a 500 error (better than a blank screen at least) as soon as the sharepoint web.config file was in the website folder.  This entire time I had focused almost exclusively on the website as being the source of the issue, it wasn't until I tried to uninstall (again) that I started thinking down another path.  This time the uninstall failed with the error:

Microsoft SharePoint 2010 uninstall did not complete successfully.
One or more required OFFICE components failed to complete successfully.  For more information consult the setup file.
This started me thinking about it's dependency on office.  I had always known Sharepoint was heavily integrated with office, but I had always assumed it was an optional feature, akin to a plugin.

Finally I happened on Marek Suscak's blog and was able to commensurate that I had gone through many of the same failed steps.  Although in my case most of the steps simply didn't apply as the values were already set to whatever the recommended fix was.  I had already installed a Complete, rather than stand-alone, instance, and I had giving it a domain account to run under.

The Solution
As a result of Marek's blog post I ended up with a copy of office installed on the server.  Sharepoint claims it does not require office to run, however the install must have fixed some of the other prerequisites that either installed corrupted or that I had tampered with because the sharepoint configuration wizard was able to get past the first couple of screens now.  However, it was still hanging on the IIS screen saying it was not installed; even though I had multiple sites running on the server.

A refreshingly fast search later I came upon a technet forum in which someone was having the same issue, and down at the very bottom, the very last suggestion was to install the legacy IIS 6 Management Compatibility features, I tried it and like magic my sharepoint admin site was suddenly working.

My Complaints
There are all sorts of things I could complain about in this install, although the worst part of it all was simply the total lack of error messages.  Even the log files didn't show anything that stood out.  Considering Microsoft's big push with .NET to give detailed error messages it felt like I had been thrown back to windows 95 days.

However, I think all of it could have been avoided if the prerequisites installer were simply better.  Either it failed, or I failed to install all the prerequisites; however it gave me a clean bill of health when I was done.  Obviously it missed a couple of very critical components.

Thursday, January 16, 2014

Windows update crashes ASP.NET web application using EnableEventValidation and EnableViewStateMac

I recently got woken up due to a production web application I am responsible for being down.  Most of the reports indicated the users were not getting .net errors, it simply was not responding to their requests for data.

When I logged onto the site, and navigated to the problem area, I was greated with this error: "A potentially dangerous Request.Form value was detected from the client"; along with the recommendation to disable EnableEventValidation if the error were incorrect.

In an effort to just get the site back up and running I flipped the switch on that page variable.  I'm not sure why the clients never saw the error, but as soon as I flipped that variable I started seeing the same problem that they were reporting; no errors, just no response to requests for data.

Since my development server was functioning perfectly I had to use Response.Write 's on the production server to start tracking down what was going on.  I was shocked to learn that the Page.IsPostBack variable was always returning true.  I got the site functioning again by finding an alternative variable I could use in its place.

With the problem under control efforts were redirected to figuring out what triggered my bad morning.

My co-worker discovered that windows updates had been applied by our hosting company to our production server.  Through the good old fashioned method of uninstalling until things started working again, he discovered that KB2894842 and KB2894843 were the culprits.  Apparently Microsoft had found a security flaw in pages that had EnableViewStateMac turned off and the fix had resulted in some rather odd results for our site.

EnableViewStateMac was turned off for our site because we were using javascript to submit data from one page to another.  It was necessary to avoid the postback mac validation error "Validation of viewstate MAC failed".  A better option might have been to use strictly .NET controls to handle postback, however it was an old site that originated in classic ASP and the javascript has always worked very well.

Later versions of .NET now have the ability to post to other pages on the site using the PostBackUrl attribute built into some controls.  I was hoping to capture the javascript generated by such a control and use it to modify my stand alone javascript to enable it to perform a successful post to the next page.

I was disappointed to discover that using the PostBackUrl attribute not only generated additional .NET javascript, but also created a __PREVIOUSPAGE hidden field with a hash value for the next page to validate.  However, I was pleasantly surprised to find out that as long as any control was rendered with that attribute then my original javascript was able to submit the page successfully with no errors.  In fact my site was now able to function with EnableViewStateMac turned on giving me back that additional piece of security.

The compromise I finally settled on was adding a button with a PostBackUrl to my master page and hiding it with CSS.

I am still not sure why the Page.IsPostBack variable stopped functioning correctly and that is part of what prompted this post.  Hopefully if I, or anyone else, runs into a similar problem in the future there will be a place to start looking due to this.