Friday, 16 September 2011

Cannot access Windows 7 Shares from a Windows XP Machine

Scenario:
Windows 7 Machines x 4 (1 x Acting as a server)
Windows XP Machines x 3
10/100/1000Mbps Network.

So I replaced a Windows XP server with a Windows 7 one and there was me thinking this was going to be easy...

From the XP machines I could ping the 'server' but couldn't get onto it, both by UNC or IP paths. I believe the error was "The specified server could not perform this action" or something to that affect.

I did recall having an issue similar tp this with Windows7 in the past and turns out the resolution is the same. You have to disable SMB version 2 so 7 support back compatibility with XP Clients. (You also sometimes get the problem with Windows SBS 2008 and XP machines.)

In regards to how SMB is designed to work see below:
  • When a Windows Server 2008/Vista "client" connects to a Windows Server 2008/Vista "server", SMB 2.0 is used.
  • When a Windows Server 2008/Vista "client" connects to a Windows 2000/XP/2003 "server", SMB 1.0 is used.
  • When a Windows 2000/XP/2003 "client" connects to a Windows Server 2008/Vista "server", SMB 1.0 is used.
  • When a Windows 2000/XP/2003 "client" connects to a Windows 2000/XP/2003 "server", SMB 1.0 is used.

Resolution
To try disabling SMB2 (which is perfectly safe) enter regedit and navigate to the following key:

HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters

Add a new REG_DWORD key with the name of "Smb2" (without quotation mark)
Value name: Smb2
Value type: REG_DWORD
0 = disabled
1 = enabled

A REBOOT IS REQUIRED FOR THIS TO WORK....


Did I solve your problem? Buy me a virtual beer by clicking on a Google ad :). Thanks!
Love to know how many other people this helps...

Friday, 26 August 2011

“The Microsoft Exchange Transport service is rejecting message submissions because the available disk space has dropped below the configured threshold”

Problem:
Microsoft Exchange 2007 presents this message in Event Viewer and you are no longer receiving emails. You may also see "Insufficient System Resources" when telnetting to the server.


Solution
We found that although the server had 6.75GB of free hard disk drive space it STILL required 'more' to process inbound emails. I ran WinDirStat which pulls out where the space is being eaten up from and deleted 24GB of useless Log files within IIS. A quick restart of the Exchange service (Transport) fixes the problem.


Did I solve your problem? Buy me a virtual beer by clicking on a Google ad :). Thanks!

Tuesday, 5 July 2011

the signature of the certificate can not be verified Exchange 2003

This took me so long to figure out and there is next to nothing on Google so hopefully this will help a few others like me who have probably reached close to the end of their tether by this point.

Everytime we opened the Public Folders section of Exchange this error was produced and so you couldnt then follow any procedures through. Unfortunately for me, I HAD to get into this console.

The error is quite simply what it says, there IS an error with your IIS SSL Certificate. Remove your SSL Certificate from IIS and you can access the Public folders, re-add the certificate again and it'll fail again.

The ultimate solution is to purchase a correctly signed certificate or if your cushty with CA services, re-issue yourself a shiny new one that matches the server name properly and then install that.

Love to know if anyone finds this useful as I spent hours with no results on the net...

Did I solve your problem? Buy me a virtual beer by clicking on a Google ad :). Thanks!

A Potential Security Concern Has Been Identified : Access Runtime 2007

We found that in Access 2007 to use a database without the trusted location error bugging the user everytime they open it wasn't quite as simple as you might initially suspect using Access 2007 Pro.

To trust a location you have to specify the path in the registry as Trusted Sources / Access Options isn't to be found in the runtime version of Access.

Navigate to the following Key:

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Security\Trusted
Locations


Create a string for:
'Path': Specify the full path to the database (excluding *.mdb)
'Description' : The description isnt relevant but from testing it appears it is required as an entry.

Additionally create a DWORD value for
'AllowSubfolders' : 1 to trust any subfolders of Path (Not a requirement)

This should eradicate the error from presenting itself, thereby trusting the database.

Did I solve your problem? Buy me a virtual beer by clicking on a Google ad :). Thanks!