Jun 07

My Webserver has different names (DNS names) and my Integrated Authentication Fails – what to do

Explanation:

Kerberos Authentication Requires SPNs for Multiple Worker Processes

You
can isolate Web sites that are in different worker processes and
running under different identities; however, unexpected IIS behavior
might occur if you use Integrated Windows authentication. Integrated
Windows authentication attempts to use Kerberos authentication, which
might not work, depending upon the identity of the worker process. To
use Kerberos authentication, a service must register its Service
Principal Name (SPN) in the account in the Microsoft Active Directory®
directory service under which the service is running. By default,
Active Directory registers the NetBIOS name or computer name and allows
the Network Service or LocalSystem user accounts to use Kerberos.
However, for Kerberos to work with the following configurations, you
must first register an SPN:

If
your site is referenced by a Windows Internet Name Service (WINS) or
Domain Name System (DNS) name that is different from the computer name
of the server running IIS (a Web farm, for example), authentication
defaults to NTLM (which is also known as Microsoft Windows NT®
Challenge/Response authentication).

If
you configure the worker process for the Web site to run as a domain
account, and you did not use a WINS or DNS name, authentication will
fail. This is because the SPN can be found, but it is registered for
the Network Service and LocalSystem user accounts, not for the domain
account under which the worker process is running.

You
can use the Setspn.exe command-line tool to register an SPN on the
account under which the worker process is running. You must be a domain
administrator to set an SPN. The Setspn.exe tool is included in
Resource Kit Tools for Windows Server 2003, available on the Windows Server 2003 Deployment Kit companion CD, or on the Web at http://www.microsoft.com/reskit.

obtained from: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/77cf4a99-9e0e-42be-8c2e-eaa4cb24c200.mspx?mfr=true

RESOLUTION

loadTOCNode(1, 'resolution');

If
this behavior occurs when the application pool is running under a local
account, follow the steps in the "Workaround" section.

To
resolve this behavior when the application pool is running under a
domain user account, set up an HTTP SPN with the NetBIOS name and the
fully qualified domain name (FQDN) of the domain user account that the
application pool is running under. To do this, follow these steps on a
domain controller:

Important An SPN for a service can
only be associated with one account. Therefore, if you use this
suggested resolution, any other application pool that is running under
a different domain user account cannot be used with Integrated Windows
authentication only.

1. Install the Setspn.exe tool. To obtain the Microsoft Windows 2000 version of the tool, visit the following Microsoft Web site:

http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&displaylang=en (http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&displaylang=en)

The
Microsoft Windows Server 2003 version of the Setspn.exe command-line
tool is available in the Windows Server 2003 Support Tools that are
included on your Windows Server 2003 CD. To install the tools,
double-click the Suptools.msi file in the Support/Tools folder.

2. Start a command prompt, and then change to the directory where you installed Setspn.exe.
3. At the command prompt, type the following commands. Press ENTER after each command:

setspn.exe -a http/IIS_computer's_NetBIOS_name DomainNameUserName

setspn.exe -a http/IIS_computer's_FQDN DomainNameUserName

Note UserName is the user account that the application pool is running under.

After
you set the SPN for the HTTP service to the domain user account that
the application pool is running under, you can successfully connect to
the Web site without being prompted for your user credentials.

WORKAROUND

loadTOCNode(1, 'workaround');To
work around this behavior if you have multiple application pools that
run under different domain user accounts, you must force IIS to use
NTLM as your authentication mechanism if you want to use Integrated
Windows authentication only. To do this, follow these steps on the
server that is running IIS:

1. Start a command prompt.
2. Locate
and then change to the directory that contains the Adsutil.vbs file. By
default, this directory is C:InetpubAdminscripts.
3. Type the following command, and then press ENTER:

cscript adsutil.vbs set w3svc/NTAuthenticationProviders "NTLM"
4. To verify that the NtAuthenticationProviders metabase property is set to NTLM, type the following command, and then press ENTER:

cscript adsutil.vbs get w3svc/NTAuthenticationProviders

The following text should be returned:

NTAuthenticationProviders       : (STRING) "NTLM"

obtained from:
http://support.microsoft.com/default.aspx?scid=kb;en-us;871179

Jun 07

Error Code: 500 Internal Server Error. The request was rejected by the HTTP filter. Contact your ISA Server administrator. (12217)

WORKAROUND

loadTOCNode(1, 'workaround');To
work around this issue, configure the Web publishing rule so that it
does not block high-bit characters. To do this, follow these steps:

1. Start the ISA Server Management tool.
2. Expand ServerName, where ServerName is the name of your ISA Server computer.
3. Click Firewall Policy,
click the Web publishing rule that you created to publish the Exchange
Server computer for access by OWA users, and then click Edit Selected Rule.
4. Click the Traffic tab, click Filtering, and then click Configure HTTP.
5. Click to clear the Block high-bit characters check box, and then click OK two times.
6. Click Apply to update the firewall policy, and then click OK.

obtained from: http://support.microsoft.com/default.aspx?scid=kb;en-us;837865

Jun 07

how to create a custom Administrative Template

Ok, I've been setting up registry keys for alot of custom applications and other things, and ofcourse, creating scripts to push them out. I just recently realized there is a more nice way of pushing this settings out and having some good wording and order of them, and that is, through Administrative templates in Group Policy. For a general overlook on how to do it, here is an example obtained from the Microsoft website, and some other good references I've found in the way. Remember, if it is not in the policies key folders for microsoft, it treats them as NT4 templates… in other words, you will have to tweak your Group Policy viewer in the filters section in order for them to be diplayed. Have fun!!

Example

loadTOCNode(2, 'summary'); The following example describes how to create a custom
Administrative Template:

1. Start Notepad.
2. Type the following code:

CLASS USER ;This modifies the HKEY_CURRENT_USER portion of the registry
; the following command creates a node called Desktop Settings
; under User Configuration.
CATEGORY !!categoryname

; the following command specifies the registry key to modify
KEYNAME "SOFTWAREPoliciesSystem"

; the following command specifies the name of the policy
; by using the variable "policyname"
POLICY !!policyname

; the following command specifies text on the Explain tab
EXPLAIN !!explaintext

; the following command creates a PART that contains a list box
PART !!labeltext DROPDOWNLIST REQUIRED

; the following statement specifies the registry value to modify
VALUENAME "NoDriveTypeAutoRun"

; the following statement populates the drop down list
ITEMLIST
NAME !!no_cd VALUE NUMERIC 181 DEFAULT
NAME !!no_drives VALUE NUMERIC 255
END ITEMLIST
END PART
END POLICY
END CATEGORY

; the following strings section assigns character strings
; to the variable names specified in the previous section
[strings]
categoryname="Desktop Settings"
policyname="Disable the autoplay feature"
explaintext="This policy disables the autoplay feature on the selected drive(s)"
labeltext="Disable autoplay on"
no_cd="CD-ROM drives"
no_drives="All drives"
3. On the File menu, click Save
As
.
4. In the Save as type box, click All
Files
.
5. Type
windows_folderinfexample.adm in the
File name box, and then click
Save.
6. Quit Notepad.
7. Click Start, point to
Programs, point to Administrative Tools, and
then click Active Directory Users and Computers.
8. Right-click the domain, and then click
Properties.
9. Click the Group Policy tab, click
New, type test policy in the
New Group Policy Object box, and then press ENTER.
10. Click Edit, right-click
Administrative Templates under User
Configuration
, and then click Add/Remove
Templates
.
11. Click Add, click
Example.adm, and then click Open.
12. After "Example" appears in the Current Policy
Templates
list, click Close.
13. Under User Configuration, expand
Administrative Templates, and then click the new
Desktop Settings node.
14. In the right pane, double-click the Disable the
autoplay feature
policy.

Note: If your new policy setting does not appear in the right pane as
you expect, right-click the new Desktop Settings node, point
to View, and then click to clear the check mark that is beside
the Show Policies Only menu item.

15. Click Enabled, and then make sure that the
policy setting contains the features that you specified in the sample
code.

reference obtained from: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q323639

Other good sites to visit:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/management/gp/admtgp.mspx
http://www.windowsdevcenter.com/pub/a/windows/2005/03/08/working_admin_templates.html
http://msgoodies.blogspot.com/

Jun 07

Information on all the Ports needed for communications and other important functions

obtained from: http://service1.symantec.com/SUPPORT/ent-security.nsf/pfdocs/2005033011582148?Open&dtype=corp

Symantec United States Document ID:2005033011582148
Last Modified:05/08/2006


Ports used for communication in Symantec AntiVirus 10.x and Symantec Client Security 3.x

Situation:

This document discusses the ports that Symantec AntiVirus 10.x
and Symantec Client Security 3.x use for communication between servers
and clients.

Solution:

Installation ports
The following table describes the network protocols and ports that must
to be available to perform network installations of the product:

Function Location Protocol Port range
Client deployment Symantec System Center TCP local ports
1024–4999
Client deployment Target clients TCP local ports
1024–5000
Client deployment Management server and target clients TCP 139
Server deployment Target servers TCP local ports
1024–5000
Server deployment Management server and target servers TCP 139, 38293

Remote installation
Remote installation tools such as ClientRemote Install and AV Server
Rollout use TCP port 139 on the targeted computers. If you plan to
install Symantec Client Security or Symantec AntiVirus onto a computer
running Windows 2003/XP, then read Windows XP Service Pack 2 or Windows Server 2003 firewall prevents remote installation.

Client/server communication ports
The following table describes the network protocols and ports that must
be available to perform the standard functions of the product.
Configurable ports are marked with an asterisk (*).

Function Location Protocol Port range
General communication Symantec System Center, servers TCP local ports
1024–4999
General communication Symantec System Center, servers, clients TCP 2967*
General communication NetWare servers TCP 2968*
General communication Clients TCP local ports
1024–5000

Rtvscan
Rtvscan makes a request to Winsock for TCP port 2967 on IP-based
networks. This is the only port needed for default client-to-server
communication. On NetWare servers, Rtvscan.nlm listens on TCP port 2968.


Note: Some versions of the Administrator's Guide erroneously state that Symantec AntiVirus uses port 2043. It actually uses port 2967.


On Windows computers, this value can be configured by using the following registry key:

HKEY_LOCAL_MACHINESOFTWAREINTELLANDeskVirusProtect6CurrentVersionAgentIPPort

If the request for the static port fails, then Rtvscan uses a dynamic
TCP port. This port is assigned by Winsock on that server and can be
different each time that Rtvscan requests a port.

Roaming clients
The SAVRoam service used by roaming clients connects to the server TCP port 2967 with a random port.

Central management ports
The following table describes the network protocols and ports required to be available in order to manage the product centrally:

Function Location Protocol Port range
Discovery Servers UDP 38293
Discovery Symantec System Center UDP local ports 1024–4999

Intel PDS Service
A Windows-based computer running a Symantec AntiVirus server
installation runs the Intel PDS Service. Intel PDS listens for ping
packets from servers. It responds with a pong packet containing
information on how to communicate with RTVScan. Intel PDS listens on
UDP port 38293 for ping packets. This value cannot be configured.

Other server-to-server communications
In server-to-server communication, the sending Symantec AntiVirus
server picks a random port, starting at TCP 1025 and moving up from
that point. From that point, traffic is returned on that random port.
To allow communication to pass through a firewall or gateway, create
rules to allow any port to accept TCP communication on 2967 and 38293
and to allow outbound TCP communication from ports 2967 and 38293:

TCP Allow 2967 to *
UDP Allow 38293 to *
TCP Allow * to 2967
UDP Allow * to 38293

On NetWare servers, Rtvscan.nlm listens on TCP port 2968. If you have NetWare servers, create the following rules:

TCP Allow 2968 to *
TCP Allow * to 2968

Ports for specific components and features
The following table describes the network protocols and ports required for certain optional components of the product:

Component Location Protocol Port range
Quarantine Central Quarantine Server TCP 2847 (HTTP)
2848 (HTTPS)
Msgsys Servers UDP 38037
Msgsys Servers TCP 38292
Legacy management Servers and clients; see below UDP 2967, 2968

Quarantine
Quarantine servers connect to the Digital Immune System by using HTTP
on TCP port 2847 and HTTPS on TCP port 2848. For information about
general configuration of Quarantine server and how to modify the TCP
ports, see the document Setting up Symantec Central Quarantine for Symantec Client Security 3.x or Symantec AntiVirus Corporate Edition 10.x.

Msgsys
Msgsys is an Alert Management System (AMS) process for generating and
sending configured AMS alerts. Msgsys communications uses UDP port
38037 and TCP port 38292.

Communication with legacy clients
To allow a Symantec AntiVirus 10.x server to communicate with clients
running Symantec AntiVirus 9.x or earlier, you must set the Server
Tuning Options in Symantec System Center. For help with this, read the
document Managing legacy clients with Symantec Client Security 3.x and Symantec AntiVirus Corporate Edition 10.x.

Because legacy clients use UDP communication, you must create rules to
allow any port to accept UDP communication on 2967 and to allow
outbound UDP communication from port 2967:

UDP Allow 2967 to *
UDP Allow * to 2967

Configuring ports to protect clients
Because these ports are listening for incoming traffic, they should be
protected from being accessed from computers that are outside of the
network. To do so, do the following:

  • On the network, block external access to these ports with a perimeter firewall.
  • On mobile computers, close the ports when the computer is not
    on the corporate network. This can be accomplished by blocking any
    unauthorized network traffic with a firewall rule or by using Location
    Awareness in Symantec Client Security to differentiate between
    corporate network traffic and other insecure communication.

References:

For a list of ports that are used in Windows 2003/2000/NT, see the Microsoft document How to Configure a Firewall for Domains and Trusts (179442).

For information about the deployment of Windows Firewall settings, see the Microsoft document Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2.

Jun 06

The service principal name for the VMRC server could not be registered. Automatic authentication will always use NTLM authentication. Error 0x80072098 – Insufficient access rights to perform the operation.

One way to solve it is available at:
http://support.microsoft.com/default.aspx?scid=kb;en-us;890893

pretty much the cause of the problems is that:
This issue occurs because the Network Service account that Virtual Server uses does not have permission to write the SPNs to Active Directory. Therefore, the SPN for vssrvc/Computer_Name and vssrvc/Fully_Qualified_Domain_Name are not registered in Active Directory.

Jun 06

Setting up Windows Firewall to allow client communications (other wise tasks from the admin console will fail)

Symantec Client Security 3.x and Symantec AntiVirus 10.x
Remote installation tools such as ClientRemote Install and AV Server
Rollout use TCP port 139 and a random TCP port between 1024 and 5000 on
the targeted computers. Windows Firewall is enabled by default in both
Windows XP Service Pack 2 and Windows Server 2003. The firewall blocks
incoming traffic to these ports, preventing installation. The easiest
way to work around this problem is to disable the Windows Firewall
before installation.

The following Microsoft documents provide information on how to disable the firewall:

After installation, you can enable Windows Firewall again. If you want
to use Symantec System Center to manage clients, you must open TCP port
2967 in Windows Firewall on the clients.

To open port 2967 on the clients

  1. On the Windows taskbar, click Start > Settings > Control Panel.
  2. Double-click Security Center.
  3. Click Windows Firewall.
  4. On the Exceptions tab, click Add Port.
  5. In the Add a Port window, in the Port Number box, type the following:

    2967

  6. Click TCP, and then click OK.
  7. In the Windows Firewall window, click OK.

For a complete list of the ports that are used for communication in Symantec AntiVirus 10.x, read Ports used for communication in Symantec AntiVirus 10.x and Symantec Client Security 3.x.

obtained from: http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2004070817071248?Open&src=&docid=2005033011582148&nsf=ent-security.nsf&view=pfdocs&dtype=corp&prod=&ver=&osv=&osv_lvl=&seg=

Jun 06

How to add a new ip to your IIS Server

Please note: You must add another ip address to your network card for you to be able to use it. This guide will help you get Internet Information Services work with that ip and not display the error message "The Network Cannot be reached". This message will only appear when you stop the website and try to start it again after making the ip change.

RESOLUTION

loadTOCNode(1, 'resolution');

To install Microsoft Windows support tools:

loadTOCNode(2, 'resolution');

1. Insert the Windows Server 2003 CD in the CD-ROM or DVD-ROM
drive.
2. When the CD opens, click Perform Additional
Tasks
.
3. Click Browse this CD.
4. Double-click Support.
5. Double-click Tools.
6. Double-click SUPTOOLS.MSI.
7. Click Next, type your information in the
Name and Organization boxes, click
Next, and then click Next on the following
screen.
8. Click Next again to start the
installation.
9. Click Finish.

To add an IP address to the IP inclusion list:

loadTOCNode(2, 'resolution');

1. Click Start, and then click
Run.
2. Type cmd, and then click
OK to open a command prompt.
3. Type the following, where
xxx.xxx.x.x is the IP address you want to add:

httpcfg set iplisten -i
xxx.xxx.x.x

When this succeeds, Httpcfg returns the following:

HttpSetServiceConfiguration completed with
0

To view additional status codes, see the Httpcfg help.

4. After the IP address is added, use the following command to
list it:

httpcfg query iplisten

Httpcfg returns the following:

IP :xxx.xxx.x.x

Important The IP inclusion list is read during startup of the HTTP service.
If you change the list, you must restart the service.

Note
The HTTP service and the HTTP SSL service are different services. The
HTTP service does not appear in the services list and must be restarted
at a command prompt. To do this, follow these steps:

1. Click Start, click Run,
and then type cmd to open a command prompt. At the
command prompt, type net stop http /y and press ENTER.
This stops the HTTP Secure Sockets Layer (SSL) service and the World Wide Web
publishing services because they are dependent on the HTTP service.
2. To start the HTTP service, type net start
w3svc
at the command prompt. This starts the HTTP SSL service and
the HTTP service.

After you add IP addresses to the IP inclusion list, you must
add each IP address that is used by a Web site. If you bind a Web site to an IP
address that is not on the list, the Web site does not start.

reference information can be found here: http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B813368

Jun 03

How to read, write and delete registry entries

this information was obtained from: http://support.microsoft.com/kb/244675/EN-US/

WSHShell = CreateObject("WScript.Shell")

*!* Create Registry Keys
WSHShell.Popup( "Create key HKCUMyRegKey with value 'Top level key'")
WSHShell.RegWrite( "HKCUMyRegKey", "Top level key")

WSHShell.Popup( "Create key HKCUMyRegKeyEntry with value 'Second level key'")
WSHShell.RegWrite( "HKCUMyRegKeyEntry", "Second level key")

WSHShell.Popup( "Set value HKCUMyRegKeyValue to REG_SZ 1")
WSHShell.RegWrite ("HKCUMyRegKeyValue", 1)

WSHShell.Popup( "Set value HKCUMyRegKeyEntry to REG_DWORD 2")
WSHShell.RegWrite( "HKCUMyRegKeyEntry", 2, "REG_DWORD")

WSHShell.Popup( "Set value HKCUMyRegKeyEntryValue1 to REG_BINARY 3")
WSHShell.RegWrite( "HKCUMyRegKeyEntryValue1", 3, "REG_BINARY")

*!* Read Registry Keys
lcValue1 = WSHShell.RegRead("HKCUMyRegKey")
WSHShell.Popup("Value of HKCUMyRegKey: " + lcValue1)

lcValue2 = WSHShell.RegRead("HKCUMyRegKeyEntry")
WSHShell.Popup("Value of HKCUMyRegKeyEntry: " + lcValue2)

lcValue3 = WSHShell.RegRead("HKCUMyRegKeyValue")
WSHShell.Popup("Value of HKCUMyRegKeyValue: " + lcValue3)

lnValue1 = WSHShell.RegRead("HKCUMyRegKeyEntry")
WSHShell.Popup("Value of HKCUMyRegKeyEntry: " + ALLTRIM(STR(lnValue1)))

lnValue3 = WSHShell.RegRead("HKCUMyRegKeyEntryValue1")
WSHShell.Popup("Value of HKCUMyRegKeyEntryValue1: " + ALLTRIM(STR(lnValue3(1))))

*!* Delete Registry Keys
WSHShell.Popup( "Delete value HKCUMyRegKeyEntryValue1")
WSHShell.RegDelete( "HKCUMyRegKeyEntryValue1")

WSHShell.Popup ("Delete key HKCUMyRegKeyEntry")
WSHShell.RegDelete( "HKCUMyRegKeyEntry")

WSHShell.Popup ("Delete key HKCUMyRegKey")
WSHShell.RegDelete( "HKCUMyRegKey")

Jun 03

Useful tools

Free repackager of InstallShield (info: http://support.installshield.com/kb/view.asp?pcode=ALL&articleid=Q108601):
   http://support.installshield.com/kb/files/Q108601/setup.exe

Orca.msi.
Note: This file comes with the Microsoft Platform SDK.
See: http://www.microsoft.com/msdownload/platformsdk/sdkupdate
Orca.msi will be installed in: "C:Program FilesMicrosoft Platform SDKBin".
See also: http://msdn.microsoft.com/library/en-us/msi/setup/orca_exe.asp

Jun 03

QuickTime silent install

Download the QuickTimeFullInstaller.exe file from:

http://www.apple.com/quicktime/download/standalone.html

And, place the below text file [or similar] in the same directory as the above installer file:

text file: QuickTimeInstaller.ini

[QTSETUP]
32Bit=FALSE
16BIT=FALSE
NO_DIALOGS=TRUE
SHOW_SAMPLE=FALSE
SHOW_README=FALSE
SHOW_PROGRAMFOLDER=FALSE
REGISTRATION_DIALOG=FALSE
LICENSE_OPTION=2
SUPPRESS_SPEED_DIALOG=TRUE
SUPPRESS_PROXY_DIALOG=TRUE
INSTALL_QTJAVA=TRUE
INSTALL_QD3D=TRUE
INSTALL_QTINFO=TRUE

[QTPREFS]
SHOW_HOTPICKS=FALSE
ConnectionSpeed=1.5 Mbps T1/Intranet/LAN
CSMultipleStreams=0

this information was obtained from: http://www.mcli.dist.maricopa.edu/director/tips/qt/014.html
more info available at: http://www.appdeploy.com/packages/detail.asp?id=123

Load more