Further to my broadband and authentication post I have found a problem using Crystal Enterprise via HTTPS.
If I connect a Microsoft CRM website via HTTP and then use the links in the product to a Crystal report all is fine. However if I use HTTPS then I get the rarther common 'Microsoft CRM Crystal Reports Logon Error. Please Verify That You Have Enough Crystal Licenses' error. Just check out the newsgroups to see how many people are getting the same problem.
I think this issue is in the WCS confiiguration for Crystal, I tried playing with setting but to no effect this far. Now for me knowing this is an issue is enough, I can work round it and have a bit more of a look later and keep the world informed
I came accross a good got-ya when using HTTP over broadband to a Microsoft IIS with active directory authentication, you keep being forced to re-authenticate. However, if you use a dial-up connection or LAN all is fine. We noticed it using Outlook Web Access and Microsoft CRM but it would be the same with any products that require more than anonymous access.
Now it seems that broadband uses a different form of caching to dial-up ISP services, DSL providers use transparent caching servers . The effect of this to convince the IIS server that each client to server request is from a different client, hence all the login dialogs.
The answer is to switch over to a HTTPS connection, the SSL connection allows the IIS server to group the client requests correctly. Just use a self signed certificate microsoft Knowledgebase Article Q228991
What a nightmare, I tried to change the settings on our 2K3 servers fax server and chaos reigned, all I wanted to do was add a modem!.
The key problem was that the Fax Server Manager would not connect to the fax service, so you cannot edit anything.
I quick look on newgroups showed I was not alone with this problem, but the answers are sketchy. Basically they boiled down to don't put your fax on a AD Domain Controller. As we only have one 'live' server this is not the most helpful solution.
Anyway this is how I got it fixed (after much trial and error):
- Load the Default Domain Controller Secuirty Policy (on Admin tools), make sure you select the controller and not the general Domain Security Policy.
- Drill down to Windows Settings/Security Settings/Local Policies/User Rights Assignment
- Edit Generate Security Audits and add Administrators, NETWORK SERVICE, LOCAL SERVICE
- Force this change to be propogated out on whatever refresh timer is setup (or use secedit /refreshpolicy machine_policy /enforce). I did the former and got a coffee!
- Now this last step appeared to be the key stage for me, and it was the one that was not in any newsgroups I found, load the fax manager with the service stopped, it automatically starts the service and all seems good in the world.
So the moral of the story, don't fiddle with the fax server if it running
Here is an interesting one for all those who are trying to debug DLL assemblies that you load dynamically in your application.
For example, you have a .Net DLL project in VS.Net 2003 that is set to launch a .Net EXE when you hit F5. In your EXE, using a File Open dialog, you select and then load your .Net DLL and run the code within it. So basically the DLL is not bound or declared to the EXE at compile time, but you still want to be able to set breakpoints in your DLL that get hit when required.
Assembly asm = Assembly.LoadFrom( “mydll.dll” );
This all works fine, you can use the classes in the assembly and debug from within VS.Net. However, the LoadFrom call does place a lock on the file that is only released when the main EXE unloads. Now this may not be an issue for you, but it was for us. You can get round this locking by creating your own Application Domain for loaded DLL assemblies but that is a bit complex. There is a simpler option; that is to load the DLL assembly via a FileStream
FileStream fs = new FileStream(“mydll.dll”,FileMode.Open);
Assembly asm = Assembly.Load(b);
This places no lock on the file, so the underlying DLL file can be deleted/replaced/reloaded to your hearts content whist the EXE is running.
However there is a problem for debugging, in VS.Net you get the message that the breakpoint in your DLL can never be reached as the symbols are not loaded for the assembly. By the way the way to check what debug symbols (if any) are loaded is to use the Modules window in VS.Net Debug|Windows.
If you use LoadFrom the assembly is loaded and any associated debug symbols (.PDB files) if present, allowing VS.Net to debug into the assembly. This is not the case with the FileStream, you only load what you ask for, if you want a .PDB as well you have to load it manually. To do this you need to use FileStream twice, the first loads the DLL into one byte array, the second loads the .PDB into another byte array. Then use another form of the Load method using both arrays.
Hope this save someone the time it lost us !
I have posted an article detailing the problems, and solutions, we found when trying to debug dynamically loaded DLLs in VS.Net. Hope this save someone the time it lost us !
The Virus Game, for Microsoft and the University of Bradford, was finished and has become an integral part of the AI for Games course at the University. The Virus Game is a tile based board game and has been produced in both a desktop and a bulk game server versions.
Black Marble's annual Tech Update for IT managers and Developer took place today. In the developer segment we reprised Chris A's & Don Box's Lap around Longhorn for the local audience. It was very well received, see you at next years update