Windows 2008 Scheduler Truncates Domain Name

I've discovered a strange bug in Windows 2008 Standard x86.  When you assign a domain account to run a scheduled  task, the name of the domain will be truncated.

In this case the domain is called "LocalDomain" and the user is "SQLAdmin".

When you create the task in Win2008 task scheduler the Domain will be truncated to "Local".

Needless to say, this will not work.  I couldn't locate any fix for this so I devised a work-around where you:

1. export the task
2. delete the task from task scheduler
3. edit the exported XML document
4. and then re-import the resulting task   

In step 3 you edit the "UserID" section of the XML document:

 
 
 
 
 
 
 
 
 
 
 
 
Save the file and then re-import the task into task scheduler and it should work as required.
 
 

IIS 6 App Pool Reset did the trick

We discovered that all of our sites running on one of our Web servers stopped working.  The web server is running Win2k3 web server running IIS6.  All of the sites on this server are running .Net Framework 1.1.  They would serve up the html code just fine but when they attempted to run any .Net application they would crash.

We tried everything to revive the sites. Reboot the server, shutting down the failover partner in the App Center cluster, reset iis, review the application and system eventlogs, review IIS logs.  Nothing gave us any useful clues as to what the problem was. 

I spoke the dev guys and server admins and no one says that they made any changes.  The last MS security updates were installed about a week ago.

I checked to see what application pool these sites used.  One site was configured with a unique application pool while the rest of the sites were configured under the default app pool.  As a test, I changed the identity that the default app pool used from the default Network Service account to the LocalService account.  The sites using that app pool started working again!  I did the same for the other app pool and that one started working as well.

Here's the strange part.  I changed the app pool identity back to the default, Network Service, and the sites continued to operate correctly.  Why or how this happened is still a mystery but I pursuing a few hunches.  One of the dev guys said that the IIS garbage collection routine might be the culprit.


Note:  The LocalService account has elevated access rights and should only used in very specific cases for security reasons. (read the section below for further information).


From MS TechNet
The identity of an application pool is the name of the account under which the application pool's worker process runs. By default, application pools operate under the Network Service account, which has low-level user access rights. That is, this account provides better security against attackers or malicious users who might attempt to take over the computer on which the World Wide Web Publishing Service (WWW service) is running. The LocalService account has low access rights as well, and is useful for situations that do not require access to resources on remote computers. You can configure application pools to run as LocalSystem, which is an account with more user rights than the Network Service or LocalService account. However, be mindful that running an application pool under an account with increased user rights presents a high security risk.

You were not connected duplicate name exists on the network

Here's the scenario; You have migrated services provided by one server to a second server.  The intention is to get rid of an older server and migrate everything to the newer server.  The new server has been given a new name to match current naming conventions.  You require that if anyone does a "net view" or a "net use" using the name of the old server, they should be able to see or use all shares on the new server.

You start by creating a a "C" name in DNS that points the host record that belongs to the new server.

From the command line execute a NETBIOS call, such as "net view", against the old server you are greeted with the following message: "You were not connected duplicate name exists on the network"

The problem is that the new server sees that you are attempting to use a "net view" with the wrong NETBIOS name.  MS has a hotfix for this but you can resolve this by making the following changes to the registry:


Windows Server 2003


To resolve this problem in Windows Server 2003, follow these steps:

Create the CNAME record for the file server on the appropriate DNS server, if the CNAME record is not already present.

Apply the following registry change to the file server. To do so, follow these steps:

Start Registry Editor (Regedt32.exe).

Locate and click the following key in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters

On the Edit menu, click Add Value, and then add the following registry value:

Value name: DisableStrictNameChecking

Data type: REG_DWORD

Radix: Decimal

Value: 1

Quit Registry Editor.

Restart your computer.



Windows 2000 Server
 
Create the CNAME record for the file server on the appropriate DNS server, if the CNAME record is not already present.

Apply the hotfix to the computer for which the CNAME record was created, not the DNS server. (Unless the DNS server and file server in question is the same computer, and then all of the changes is applied is to that server.) This hotfix affects the LAN Manager Server Service and does not affect DNS functionality.

Apply the following registry change to the file server to which you installed the hotfix. To do so:

Start Registry Editor (Regedt32.exe).

Locate and click the following key in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters

On the Edit menu, click Add Value, and then add the following registry value:

Value name: DisableStrictNameChecking

Data type: REG_DWORD

Radix: Decimal

Value: 1

Quit Registry Editor.

Restart your computer

Great Plains - You're attempting to log in from a data source using a trusted connection

If you logon to Great Plains 8.0 or 9.0 and get this message:

"You're attempting to log in from a data source using a trusted connection. Update the SQL Server settings for this data source to disable trusted connections and try logging in again"

This turns out to be a known Great Plains issue.  If the account name is all lower case: jsmith and you attempt to logon with JSmith you will get the above mis-leading message. 

The following Microsoft Dynamics Knowledge Base article may of interest to you.

ArticleID: 913339.

Error message when you log in to Microsoft Dynamics GP after you update from an earlier version or service pack: 'You're attempting to log in from a data source using a trusted connection. Update the SQL Server settings for this data source'


SYMPTOMS

When you log in to Microsoft Dynamics GP 9.0 or to Microsoft Business Solutions - Great Plains 8.0 with Service Pack 4a for the first time after you update from an earlier version or after you install a service pack, you are prompted to change the password. When you change the password, you receive the following error message:

You're attempting to log in from a data source using a trusted connection. Update the SQL Server settings for this data source to disable trusted connections appears



CAUSE

This problem occurs because the user ID contains uppercase letters. However, you entered all lowercase letters.




RESOLUTION

To resolve this problem, use one of the following methods.



Method 1

To resolve this problem, follow these steps:

1. Start Microsoft Dynamics GP 9.0 as the sa user.

2. On the Tools menu, point to Setup, point to System, and then click User.

3. In the User ID box, click the lookup, highlight the user who is experiencing this problem, and then click Select.

4. In the Password box, re-type a password, and then click Save.



Method 2

To resolve this problem, follow these steps:

1. Start Microsoft Business Solutions - Great Plains 8.0 as the sa user.

2. On the Tools menu, point to Setup, point to System, and then click User.

3. In the User ID box, click the lookup button, highlight the user who is experiencing this problem, and then click Select.

4. Verify that the correct user ID is being used to login. Then re-enter the user password.

5. Click Save.



STATUS

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.


________________________________________

APPLIES TO

• System Manager, when used with:

Microsoft Dynamics GP 9.0

Microsoft Business Solutions–Great Plains 8.0


Keywords: kbmbsupgrade kbmbspartner kberrmsg kbbug kbmbsmigrate kbprb KB913339

Unable to copy files to Vista, Win7, Win2008

I have a VM running on a VMWare 2.0 host. The VM is running Windows 2008 SP2 x86. If I am logged on the VM and I try to copy a file/files to it, I receive the following error:

"Network Error: There is a problem accessing [insert name of file you are copying]. Make sure you are connected to the network and try again"

This is a frustrating one because if you try to resolve it by doing what most people do and that is to search "Bing, Google, Yahoo" for such phrases as : "Network Error: There is a problem accessing" or "Make sure you are connected to the network and try again" you will get led down many wrong paths; i.e. UAC, anti-virus client, firewall issue, domain credentials, etc. (But hopefully you will get this blog first).

I remember I ran into this issue on a Windows 2003 server previously and the fix was to go into Add Remove programs and make sure that IE ESC was cleared for Administrators.

So, from experience, the first thing I checked was that this was not turned on for Administrators on this Windows 2008 server:

So I tried copying over the file again and got the same error message: "Network Error: There is a problem accessing [insert name of file you are copying]. Make sure you are connected to the network and try again".

Hmm, I'm quite sure that this was the fix, but then I noticed that when I opened IE 8 I could see that IE ESC was not really turned off.  I guess that a group policy has been applied to lock this down.

I had to go to the next step and open IE Options: go to Internet Options, click on the "Security" tab and click on the "Local Intranet" icon and then click the "Sites" button, and then click "Advanced". Add the file server name to the list with this format:

\\servername or file://servername/ or domain-wide file://*.domain.com/

Try your copy now and it will work.

For security reasons you should probably re-enable IE ESC.