|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Welcome to my results from changing
the IP address of a Small Business Server which has been in use for 5 months.
The server IP address change took a
minor amount of time however the workstations and associated services took a
considerable longer period of time.
Fault finding and repairs to
settings, to allow users access to their items was not immediate or straight
forward.
The SBS 2003 servers IP
address was changed using the Microsoft recommended Wizard (Change Server IP
wizard). This tool is not available for SBS 2000 or Windows Server 2000/2003.
NB: The
Wizard will only work if the SBS 2003 server has SBS 2003 SP1 installed. If it
only has Windows 2003 server SP1 installed, the Wizard will cause issues and
should not be run until SBS 2003 SP1 has been downloaded and installed.
Time Clock's, Thin clients, IP
docket printers etc require to be the first item to change.
The IP Address of Photocopiers was
changed next. Any Copier based templates, file stores, DNS, Gateway, WINS, OCR
tool/service access and desktop shortcuts all needed to be modified. The additional TCP/IP printer ports created
by the original installation of the printer needed to be removed. Change IP Address Tool in SBS Management Console (SBS 2003 only)
The 'Change IP Address' wizard was
run. This is a simple matter of typing
in the new IP and Netmask. These tasks
need to be manually configured on other versions of server.
Details of what this wizard actually
changes are below, this information is from the Windows Help function within
the Change IP Address wizard:
When you run the Change IP Address Tool, the following
changes are made:
Network services configured by the Change IP Address Tool: Notes:
o
If your server has only one network adapter and
you have a broadband connection that uses a router to connect to the Internet,
the router option is not updated as this address is set to the IP address of
the router itself.
o
If you are using an existing DHCP server service
on the local network, you must ensure that the new IP address of your server's
local network adapter is excluded from the range of IP addresses assigned out
by the device.
o
Configures
http.sys driver to only bind to the local network adapter and the loopback
adapter. By doing this, IIS will only listen to Web requests from the local
network adapter. This allows ISA Server to monitor incoming Web requests from
the Internet.
o
Disables socket pooling, which enables ISA
Server to use port 80, so ISA Server can monitor incoming Web requests.
A couple of the issues listed below
can be fixed at this point, if the server is rebooted. Roaming profiles and policies, and some DNS
issues are examples.
1.
DNS Reverse lookup zones did not get
recreated
2.
Nslookup would not find the local
DNS server. The service was on the same machine.
3.
Network DNS had issues with name
resolution. The ISA Client could not
find the server when the server Name was used, it only worked when an IP was
used.
4.
Terminal Services client's logon
scripts appear to run, but it did not setup network drives correctly.
5.
Some workstations could not connect
to their roaming profile.
6.
The Active Directory policies on
Server were incorrectly referenced. The policies did not roam.
7.
Offline files on all workstations
were looking for old server.
8.
The "My Documents" folder remained
offline, the redirection is to old server IP address.
9.
The Trend Micro Officescan client
was disconnected on all workstations.
10.
The Copier shared drives and OCR pointed to incorrect IP Addresses. The
templates required to be reconfigured on the copier so that document scans are
sent to the correct shares on the server.
IMSS needed the new Copier IP address to allow scan to email features to
work.
11.
The WINS records were not flushed. Old IP range still has records in
WINS. (These were deleted)
12.
Third party web based management consoles were still set to old IP. e.g. Trend Micro consoles do not work, and
need their IP addresses changed to new server IP. Scan mail, Officescan and IMSS all registered
in IIS with specific IP addresses, Certificates and proxy update settings which
all needed changing.
13.
Printer IP ports on all client machines remained on old printer
addresses.
1.
Issues 1. to 6. were essentially DNS
issues. DNS was reinstalled by the
following method.
2.
Offline files needed to be
recreated. This is done by disabling
offline files, deleting the contents of the store and then re-enabling them and
setting up the appropriate synchronizations.
3.
Use the "Configure My Documents
Redirection" wizard to disable the redirection. Once people are logged off and
you have confirmed the redirection is gone, run the wizard again to replace the
redirection.
4.
The easiest way to set Officescan up
correctly was to uninstall it from both the server and workstations and install
it all again.
5.
Any shortcuts to the copier's shared
drives needed to be recreated for the users.
6.
For the WINS records, simply delete
any stale records in WINS that are on the old IP range.
7.
For any applications that have a web
based administration console, you will need to fix them on a case by case
basis. Hopefully they will have a link
somewhere that is editable.
8.
Anyone printing to a network printer
will need their network ports recreated or the printer drivers reinstalled.
9.
Any other links to various applications and resources will need to be
recreated. Unfortunately this may not be
evident immediately and will have to be fixed as the issues arise.
10.
As administrator we needed to run "Ipconfig /release", "ipconfig /renew"
on all workstations.
11. The logon script needed to be edited
manually for the new IP printers and UNC links.
12.
The CEICW wizard and RRAS wizard needed to be re run
13.
It was required to manually change the RRAS and VPN DHCP and Static
pools.
14.
The proxy settings stored in the Active Directory polices needed to be
re created.
15.
The ISA client settings were edited at the server.
16.
The ISA client settings for previously deployed clients were edited at
the workstations.
17.
Excess and redundant printer TCP/IP ports were removed.
18.
GPO policies in the Active Directory were functional after the DNS
repair.
19.
Roaming profiles were repaired when DNS became functional.
20.
Trend Micro IMSS email gateway was edited to allow the servers new IP
address to relay email. The old address was removed.
21.
Veritas backup, APC power chute, Trend Micro and other programs had
their alert emails reconfigured for the new email server address.
22.
It was required to edit the URL for the shortcut to IMSS
23.
DNS and Wins was checked and stale records were deleted (Stale records
were coming from the workstations with old settings). Update June 2008: I still generally minimize the issues with
faxing by using External, Serial, V90 trusted modems. I do not use V92, USB
or software modems. (The modems I use are getting harder to find). You can try; Sometimes, things just don't work. Now you need
to get some error logs. Some of the logs needed (e.g. the
T30 log) needs some
registry tweaking or configuration in SBS 2003. In SBS 2000 there was a separate
tool that PSS support would send you specifically for T30 logs. Gather the following logs files;
The Activity Log settings can be found
within the Fax Service Manager. Right-click on Fax (Local) and select
Properties. Select the Activity Logging TAB. From there you’ll see
the “Activity Log Folder Location” path. Highlight the path and copy it
into the Start\Run\<path>. Within the ActivityLog folder you’ll find
Inboxlog.txt and Outboxlog.txt. You might need to enable logging. T.30 logging is not enabled by default in
Windows Server 2003 and SBS 2003 and must be enabled manually via the registry.
To enable T.30 debug logging of fax transmissions on your PC, please do the
following: Using regedit,
browse to the following key DebugContextEx to 0xffffffff (8 f’s) DebugFormatEx to 0xbbffffff (2 b’s and 6 f’s) Stop and restart the Fax Service so these settings will take effect. This then generates the file named T30DebugLogFile.txt and it can be found at %windir%\temp or at %SystemDrive%\Documents and Settings\NetworkService\Local Settings\Temp Note: The NetworkService folder is hidden by default therefore you will have to unhide this folder to get to the file. After you are done, please delete (or set to zero) all the values set/created above to stop debug logging. Restart the Fax Service. Now, you need to gather this data along with one last item and get it to someone (prefferably Microsoft) to deal with your problem. I certainly can help but ultimately, they might need to pull everything apart to solve the issue.(It could be something unrelated like the RRAS service grabbing the modem). Microsoft will ask for a Directory Service Edition MPS report: Please refer to the URL below and run the Directory Service Edition (MPSRPT_DirSvc.EXE) tool on the problematic computer: Microsoft Product Support's Reporting Tools A CAB file will be generated as: %systemroot%\MPSReports\DirSvc\Logs\Cab\%COMPUTERNAME%_MPSReports_.CAB Zip up all the log files and send them and the cab file to the person who is helping you. I would love to see a copy of your user login script. Thank you, Jack * Well Jack, the script is on it's way to you. As other people have started asking for it, I will make it available on my tools download page at the end of this year (05). The script will show how: NEW! Microsoft has moved Sysinternals to Here Update 10/07/06, Refer to my new scripts page Michael, I have an SBS 2000 server and a Win 2k3 box I am installing Exchange 2k3 Ent. Edition on. Do I need to make the 2k3 box a DC? Or can I just use it as a Member server and install Exchange on that? Thanks, Don * Hello, I personally would make the Windows 2003 server a DC (This is not necessarily Microsoft recommended). This will be a part of the SBS domain and take on it's AD etc but has the great advantage of taking the load of the SBS box. Exchange is very AD intensive. This gives you the added advantage of a backup DC if the SBS box becomes to busy to handle AD queries and you can also setup DFS file structures etc so that you have a complete disaster recovery solution. This is how I would do it in an SBS environment as you are limited to the number of mailboxes and connections (SBS 2000 can only have 50 connections) and a high powered server should not struggle. This is different for an enterprise server (non SBS with more than 50-75 users). Exchange needs AD in some way. It can be on another box and the box can be a member server only. If you are going to thoroughly use Exchange and the SBS box is not being used heavily, it is a recommended practice by Microsoft that Exchange is not on the same box as the AD. So, either way it will work. It is up to your hardware, environment and practices as to how the Exchange or AD server will be affected. I guess the short answer is, no, it does not need to be a DC. Thanks for the great question Got a question to make ya think.. I want to get our profiles off the external drive on our DC, and copy them to another server where there is a RAID and plenty of space. Even being an administrator I cant do this copy unless I take ownership of the profiles which I don’t want to do, so I have to copy them under the system account, my question is how can I do that effectively. My thoughts were: Restore from Veritas from the night before and point it to restore to the server, this would probably have to be done on a weekend. or Obtain a VBS script that uses the system account through WMI to do that copy – im not sure if this is possible I guess the next step in this process would be to point the users account properties to there new profile location, and im guessing there is a script somewhere on the net can search through a certain organization unit and change certain properties… What are your thoughts on this Neil Hello Neil, Just change the path in the AD (users properties) and let the user workstations roam their local version of the profile back to the new location. Easy solution. Topics to come Things not to do, and why
( ) |
|
|
|
|
|
|
