On a problem Mac, check if the mit.edu.kerberos file has been modified back to a default. We’ve been seeing machines overwriting our custom file and replacing it with a default one. If the file has been changed try this:
In the default file look for the line that says [libdefaults]. Chances are the only thing under it will be “dns_fallback = no” or it could give you a realm list. Either way, cut and paste from your modified edu.mit.kerberos file everything under [libdefaults] line. Don’t replace the Kerberos file this time: cut and paste into it.
After you have done this go System/Library/Core Serivces/Kerberos.app and delete any Kerberos ticket you might find.
Restart and try to log in again.
On a problem Mac you could also try stopping and restarting directory services:
Sudo killall DirectoryServices
The service will start again automatically.
Then check that AD is in the search path: dscl /Search –read / CSPSearchPath SearchPolicy
It should return:
/Local/Default,
/BSD/local
Active Directory/All Domains
Lastly, if you are still having problems, turn on Directory Services logging at startup:
Sudo killall –USR1 DirectoryServices
Touch /Library/Preferences/DirectoryService/.DSLogDebugAtStart
After the restart the logs can be found in:
/Library/Logs/DirectoryService/DirectoryService.debug.log
Wednesday, October 29, 2008
Print spooler on client PCs (XP) falling over
In Amsterdam we had a problem where the print spooler was repeatedly stopping on the server. The fix was to translate TT fonts to bitmap in each printer's advanced settings (right-click on the printer and go to properties)
More details:
The printer drivers were upgraded, and used PCL5 rather than PCL6, this
stopped the print spooler from crashing.
A symptom arised that people were getting garbage printed out when
printing from Outlook (other apps OK). This issue was resolved by
forcing the default option of printing TT fonts as bitmaps.
More details:
The printer drivers were upgraded, and used PCL5 rather than PCL6, this
stopped the print spooler from crashing.
A symptom arised that people were getting garbage printed out when
printing from Outlook (other apps OK). This issue was resolved by
forcing the default option of printing TT fonts as bitmaps.
OS X Tiger slow logins: LDAPv3 fix
I can confirm that if I remove the LDAPv3 settings from my Macs, then the boot process is MUCH MUCH faster...reduced from minutes to seconds on my really fast Macs. Removing the entry completely (or disabling it by un-checking the check mark on the main Directory Access screen) will make my machines boot faster.
Mac Binding problem and fix: report from Hamburg
Problems
The HAM office reported several problems:
Slow log in on Macs (up to an hour)
Macs which would not bind
Macs would take a long time to bind
Mac which were bound not having network accounts available at log in
Users on bound Macs unable to log into the computer if it was disconnected from the network (a real problem for laptops)
When the local DC was taken off-line the Macs could not log in
When the office was removed from the WAN, the Macs could not log in
I believe that we have now resolved all of the above issues, however the last one involves a change which the Directory Team is not in favour of.
We have a full testing matrix but I’ll hit the highlights:
The local DC’s error log showed a good number of replication errors; it also had the primary and secondary DNS servers reversed and 28 updates and critical patches waiting to be applied. The DNS entries were corrected, patches applied and the DC was restarted- it seems to be operating well now.
On a problem Mac (network accounts unavailable and the user couldn’t log in even if they had a mobile account) we did two things: deleted the edu.mit.kerberos file from Library/Preferences and deleted the live Kerberos ticket (sometimes, if a user was having problems logging in they did not have a Kerberos ticket at all). After a restart, network accounts became available after about 15 seconds and after the user entered their AD credentials it took 10 seconds further to completed the login process.
Checking the edu.mit.kerberos file after login we found that it had been successfully recreated and had the correct entries for the site and the EMEA realm:
Kdc = hamgdc02.xxx.xxx.xxx.com.:88
Kdc = amsgdc02.xxx.xxx.xxx.com.:88 (this entry sometimes displayed other EMEA DCs)
Admin_server = hamgdc02.xxx.xxx.xxx.com.
Admin_server = amsgdc02.xxx.xxx.xxx.com. (this entry sometimes displayed other EMEA DCs)
All of the above entries are exactly what they should be. Before we made changes to the DC and rebooted it, the edu.mit.kerberos files could have any random DC within the global IPG network (we found them pointing to Hong Kong, Dublin, Milan, etc.)
If we disconnected this Mac from the network the user could still log in using their mobile account.
If we disconnected the network cable from the DC, after about 60 seconds network accounts on the Mac became available and the user could log in (it took a while, about 90 seconds but it still worked). If the Mac had either no Kerberos ticket and/or a edu.mit.kerberos file with improper entries, the client could never log in if the DC was unplugged from the network.
If we disconnected the DC from the WAN and connected it via cross-over cable to a PC (simulating the office dropping its WAN connection) the PC was, after a while, able to authenticate an AD user and log in. If we connected a Mac to the DC with a cross-over cable, network accounts would never become available and we could not log in using an AD account.
If I added ldap and kerberos entries into DNS/emea.xxx.xxx.com/msdcs/dc/_tcp for the local then a Mac connected via crossover cable to the DC would, after about 60 seconds, have network accounts become available and an AD user can log in (takes about 90 seconds).
If I removed the DNS entries, the Mac was unable to log in and network accounts never became available.
Conclusions
“Cleaning up” the DC and rebooting it allowed the Macs to generate properly configured edu.mit.kerberos files.
Based on our testing it would seem that deleting the edu.mit.kerberos file along with the active Kerberos ticket and rebooting the Mac fixes the problem of unavailable network accounts and slow user log in. It also seems to make the Macs bind faster and more reliably.
Once a proper edu.mit.kerberos file has been generated, removing the Mac from the LAN or disconnecting the DC from the LAN still allows for user log in. However, if the office loses its connectivity to the WAN, Macs which are still connected to the LAN are unable to log in at all unless we add the above mentioned DNS entries.
It should be noted that none of the Macs we tested, nor any user’s Mac which had authentication problems during the time I was in the office, ever unbound themselves from the AD. Not being able to authenticate is not necessarily a symptom of a binding problem.
The HAM office reported several problems:
Slow log in on Macs (up to an hour)
Macs which would not bind
Macs would take a long time to bind
Mac which were bound not having network accounts available at log in
Users on bound Macs unable to log into the computer if it was disconnected from the network (a real problem for laptops)
When the local DC was taken off-line the Macs could not log in
When the office was removed from the WAN, the Macs could not log in
I believe that we have now resolved all of the above issues, however the last one involves a change which the Directory Team is not in favour of.
We have a full testing matrix but I’ll hit the highlights:
The local DC’s error log showed a good number of replication errors; it also had the primary and secondary DNS servers reversed and 28 updates and critical patches waiting to be applied. The DNS entries were corrected, patches applied and the DC was restarted- it seems to be operating well now.
On a problem Mac (network accounts unavailable and the user couldn’t log in even if they had a mobile account) we did two things: deleted the edu.mit.kerberos file from Library/Preferences and deleted the live Kerberos ticket (sometimes, if a user was having problems logging in they did not have a Kerberos ticket at all). After a restart, network accounts became available after about 15 seconds and after the user entered their AD credentials it took 10 seconds further to completed the login process.
Checking the edu.mit.kerberos file after login we found that it had been successfully recreated and had the correct entries for the site and the EMEA realm:
Kdc = hamgdc02.xxx.xxx.xxx.com.:88
Kdc = amsgdc02.xxx.xxx.xxx.com.:88 (this entry sometimes displayed other EMEA DCs)
Admin_server = hamgdc02.xxx.xxx.xxx.com.
Admin_server = amsgdc02.xxx.xxx.xxx.com. (this entry sometimes displayed other EMEA DCs)
All of the above entries are exactly what they should be. Before we made changes to the DC and rebooted it, the edu.mit.kerberos files could have any random DC within the global IPG network (we found them pointing to Hong Kong, Dublin, Milan, etc.)
If we disconnected this Mac from the network the user could still log in using their mobile account.
If we disconnected the network cable from the DC, after about 60 seconds network accounts on the Mac became available and the user could log in (it took a while, about 90 seconds but it still worked). If the Mac had either no Kerberos ticket and/or a edu.mit.kerberos file with improper entries, the client could never log in if the DC was unplugged from the network.
If we disconnected the DC from the WAN and connected it via cross-over cable to a PC (simulating the office dropping its WAN connection) the PC was, after a while, able to authenticate an AD user and log in. If we connected a Mac to the DC with a cross-over cable, network accounts would never become available and we could not log in using an AD account.
If I added ldap and kerberos entries into DNS/emea.xxx.xxx.com/msdcs/dc/_tcp for the local then a Mac connected via crossover cable to the DC would, after about 60 seconds, have network accounts become available and an AD user can log in (takes about 90 seconds).
If I removed the DNS entries, the Mac was unable to log in and network accounts never became available.
Conclusions
“Cleaning up” the DC and rebooting it allowed the Macs to generate properly configured edu.mit.kerberos files.
Based on our testing it would seem that deleting the edu.mit.kerberos file along with the active Kerberos ticket and rebooting the Mac fixes the problem of unavailable network accounts and slow user log in. It also seems to make the Macs bind faster and more reliably.
Once a proper edu.mit.kerberos file has been generated, removing the Mac from the LAN or disconnecting the DC from the LAN still allows for user log in. However, if the office loses its connectivity to the WAN, Macs which are still connected to the LAN are unable to log in at all unless we add the above mentioned DNS entries.
It should be noted that none of the Macs we tested, nor any user’s Mac which had authentication problems during the time I was in the office, ever unbound themselves from the AD. Not being able to authenticate is not necessarily a symptom of a binding problem.
Mac bining and SRV records (part 1)
Form MacWindows:
I recently had an issue whereby all OS X 10.4 clients/servers I tried to bind to a customer's Active directory would fail with "unknown error" at Step 5. The ADPlugin log would show the binding failing while trying to set the computer password. I found your very useful pages through googling the issue, and thought I would let you know what eventually fixed my issue.
I believe I had two issues causing this binding problem, both DNS related.
The first was that some SRV records for one of their domain controllers were missing from DNS (in particular _ldap and _kpasswd). Running "nltest /dsregdns" on the missing server should sort this, but they should also be added in automatically when the Netlogon service starts on the server, so if they are missing there could be some wider domain controller issue to investigate.
The second problem (once the SRV records were sorted), and the one that was causing the step 5 failure, was that the domain controllers were multi-homed: they each had more than one IP address, and these addresses were all registered in DNS. For some reason, the AD bind process would retrieve the correct IP from DNS for each step until step 5 when it would try and talk to the servers second IP for the kpasswd (464 UDP) part of the bind. This would fail.
To fix this, if possible remove the second IP address from the server. If you can't do this, remove the server A record in DNS that points to the second IP address (you might have to go in to the TCP/IP properties on the server and tell it "not to register this connection in DNS" if you leave more than one IP address on the server, else it will re-register it in DNS). This fixed the issue for me
I recently had an issue whereby all OS X 10.4 clients/servers I tried to bind to a customer's Active directory would fail with "unknown error" at Step 5. The ADPlugin log would show the binding failing while trying to set the computer password. I found your very useful pages through googling the issue, and thought I would let you know what eventually fixed my issue.
I believe I had two issues causing this binding problem, both DNS related.
The first was that some SRV records for one of their domain controllers were missing from DNS (in particular _ldap and _kpasswd). Running "nltest /dsregdns" on the missing server should sort this, but they should also be added in automatically when the Netlogon service starts on the server, so if they are missing there could be some wider domain controller issue to investigate.
The second problem (once the SRV records were sorted), and the one that was causing the step 5 failure, was that the domain controllers were multi-homed: they each had more than one IP address, and these addresses were all registered in DNS. For some reason, the AD bind process would retrieve the correct IP from DNS for each step until step 5 when it would try and talk to the servers second IP for the kpasswd (464 UDP) part of the bind. This would fail.
To fix this, if possible remove the second IP address from the server. If you can't do this, remove the server A record in DNS that points to the second IP address (you might have to go in to the TCP/IP properties on the server and tell it "not to register this connection in DNS" if you leave more than one IP address on the server, else it will re-register it in DNS). This fixed the issue for me
OS X servers unbinding from domain (from MacFixIT)
Jose Richard sent us a fix to the problem of Mac OS X Server periodically unbinding from Active Directory:
Here's a solution to permanently correct the periodically loses of AD connection. Next time you do an unbind/bind to correct the problem, after the bind step do the following:
- Run dsconfigad -enablesso after binding
- Verify the following options in /etc/smb.conf:
* workgroup = WGP [# this should be the netbios]
* name of your AD domain
* security = ads [# use "ads" for this value]
* "domain" will periodically change the computer trust account and break your binding to AD.
* netbios name = computername [# this should be the same as the computer name you used in Directory Access/Directory Utility to bind to AD]
* use spnego = yes [# this should always be "yes" -- it enables negotiation of the authentication methods]
* realm = WGP.COMPANY.COM [# This should be your AD domain in all caps: it is case sensitive!
If you’ve tried this please let us know.
July 11, 2007
Bob Nance has verified a previously reported fix for Mac OS X Server periodically unbinding from Active Directory:
As reported, this problem has beens solved with the command:
dsconfigad -enableSSO
It appears that the problem was that the Kerberos ticket getting ticket was not being renewed without the additional command. Now, it all works as it's supposed to.
If you can shed further light please let us know.
More news on the MacWindows home page.
Clarification on fix for OS X Server unbinding from AD
July 30, 2007
Sochet Ly previously reported the problem of Mac OS X Server periodically unbinding from Active Directory. Ly had success with the suggested fix from June 26, but makes a note about its implementation:
I first tried the suggestion, but not straight after rebinding it to AD: that doesn't seem to work. Now I just unbind and rebind to AD, then ran dsconfigad -enableSSO.
After nearly 3 week without have to rebind to AD, I am happy to report that running dsconfigad -enableSSO command straight after rebinding to AD did the trick. So the key thing for me is ran dsconfigad -enableSSO straight after rebinding OD-AD.
Here's a solution to permanently correct the periodically loses of AD connection. Next time you do an unbind/bind to correct the problem, after the bind step do the following:
- Run dsconfigad -enablesso after binding
- Verify the following options in /etc/smb.conf:
* workgroup = WGP [# this should be the netbios]
* name of your AD domain
* security = ads [# use "ads" for this value]
* "domain" will periodically change the computer trust account and break your binding to AD.
* netbios name = computername [# this should be the same as the computer name you used in Directory Access/Directory Utility to bind to AD]
* use spnego = yes [# this should always be "yes" -- it enables negotiation of the authentication methods]
* realm = WGP.COMPANY.COM [# This should be your AD domain in all caps: it is case sensitive!
If you’ve tried this please let us know.
July 11, 2007
Bob Nance has verified a previously reported fix for Mac OS X Server periodically unbinding from Active Directory:
As reported, this problem has beens solved with the command:
dsconfigad -enableSSO
It appears that the problem was that the Kerberos ticket getting ticket was not being renewed without the additional command. Now, it all works as it's supposed to.
If you can shed further light please let us know.
More news on the MacWindows home page.
Clarification on fix for OS X Server unbinding from AD
July 30, 2007
Sochet Ly previously reported the problem of Mac OS X Server periodically unbinding from Active Directory. Ly had success with the suggested fix from June 26, but makes a note about its implementation:
I first tried the suggestion, but not straight after rebinding it to AD: that doesn't seem to work. Now I just unbind and rebind to AD, then ran dsconfigad -enableSSO.
After nearly 3 week without have to rebind to AD, I am happy to report that running dsconfigad -enableSSO command straight after rebinding to AD did the trick. So the key thing for me is ran dsconfigad -enableSSO straight after rebinding OD-AD.
Avaya phone reset
Please see sequence below to basically reset a phone to factory standards.
On a working phone….
Press “Mute” button
Type “CRAFT” (27238) on keypad
Press #
Arrow down to clear
Select “Start”
One a problematic phone that cannot find dhcp or displays an error and is continuously resetting in a loop.
When it displays “* to programme”
Press * when prompted and enter code (craft) as mentioned above. Exact same process as above to clear values.
On a working phone….
Press “Mute” button
Type “CRAFT” (27238) on keypad
Press #
Arrow down to clear
Select “Start”
One a problematic phone that cannot find dhcp or displays an error and is continuously resetting in a loop.
When it displays “* to programme”
Press * when prompted and enter code (craft) as mentioned above. Exact same process as above to clear values.
PCExec instructions (tool to remotely run commands on a PC)
Download and instructions here: http://www.microsoft.com/technet/sysinternals/Security/PsExec.mspx
PsExec v1.92
By Mark Russinovich
Published: November 27, 2007
Introduction
Utilities like Telnet and remote control programs like Symantec's PC Anywhere let you execute programs on remote systems, but they can be a pain to set up and require that you install client software on the remote systems that you wish to access. PsExec is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software. PsExec's most powerful uses include launching interactive command-prompts on remote systems and remote-enabling tools like IpConfig that otherwise do not have the ability to show information about remote systems.
Note: some anti-virus scanners report that one or more of the tools are infected with a "remote admin" virus. None of the PsTools contain viruses, but they have been used by viruses, which is why they trigger virus notifications.
Top of page
Installation
Just copy PsExec onto your executable path. Typing "psexec" displays its usage syntax.
PsExec works on Windows Server 2008, Vista, NT 4.0, Win2K, Windows XP and Server 2003 including x64 versions of Windows.
Top of page
Usage
See the July 2004 issue of Windows IT Pro Magazine for Mark's article that covers advanced usage of PsExec.
usage: psexec [\\computer[,computer2[,...] | @file][-u user [-p psswd]][-n s][-l][-s|-e][-x][-i [session]][-c [-f|-v]][-w directory][-d][-][-a n,n,... ] cmd [arguments]
computer
Direct PsExec to run the application on the computer or computers specified. If you omit the computer name PsExec runs the application on the local system and if you enter a computer name of "\\*" PsExec runs the applications on all computers in the current domain.
@file
Directs PsExec to run the command on each computer listed in the text file specified.
-a
Separate processors on which the application can run with commas where 1 is the lowest numbered CPU. For example, to run the application on CPU 2 and CPU 4, enter: "-a 2,4"
-c
Copy the specified program to the remote system for execution. If you omit this option then the application must be in the system's path on the remote system.
-d
Don't wait for application to terminate. Only use this option for non-interactive applications.
-e
Does not load the specified account's profile.
-f
Copy the specified program to the remote system even if the file already exists on the remote system.
-i
Run the program so that it interacts with the desktop of the specified session on the remote system. If no session is specified the process runs in the console session.
-l
Run process as limited user (strips the Administrators group and allows only privileges assigned to the Users group). On Windows Vista the process runs with Low Integrity.
-n
Specifies timeout in seconds connecting to remote computers.
-p
Specifies optional password for user name. If you omit this you will be prompted to enter a hidden password.
-s
Run remote process in the System account .
-u
Specifies optional user name for login to remote computer.
-v
Copy the specified file only if it has a higher version number or is newer on than the one on the remote system.
-w
Set the working directory of the process (relative to the remote computer).
-x
Display the UI on the Winlogon desktop (local system only).
-priority
Specifies -low, -belownormal, -abovenormal, -high or -realtime to run the process at a different priority. Use -background to run at low memory and I/O priority on Vista.
program
Name of the program to execute.
arguments
Arguments to pass (note that file paths must be absolute paths on the target system)
You can enclose applications that have spaces in their name with quotation marks e.g. "psexec \\marklap "c:\long name\app.exe". Input is only passed to the remote system when you press the enter key, and typing Ctrl-C terminates the remote process.
If you omit a username the remote process runs in the same account from which you execute PsExec, but because the remote process is impersonating it will not have access to network resources on the remote system. When you specify a username the remote process executes in the account specified, and will have access to any network resources the account has access to. Note that the password is transmitted in clear text to the remote system.
You can use the current version of PsExec as a Runas replacement when you target the local system because PsExec does not require you to be an administrator.
Top of page
Examples
This article I wrote describes how PsExec works and gives tips on how to use it:
http://www.winnetmag.com/Windows/Issues/IssueID/714/Index.html
The following command launches an interactive command prompt on \\marklap:
psexec \\marklap cmd
This command executes IpConfig on the remote system with the /all switch, and displays the resulting output locally:
psexec \\marklap ipconfig /all
This command copies the program test.exe to the remote system and executes it interactively:
psexec \\marklap -c test.exe
Specify the full path to a program that is already installed on a remote system if its not on the system's path:
psexec \\marklap c:\bin\test.exe
Run Regedit interactively in the System account to view the contents of the SAM and SECURITY keys::
psexec -i -d -s c:\windows\regedit.exe
To run Internet Explorer as with limited-user privileges use this command:
psexec -l -d "c:\program files\internet explorer\iexplore.exe"
PsExec v1.92
By Mark Russinovich
Published: November 27, 2007
Introduction
Utilities like Telnet and remote control programs like Symantec's PC Anywhere let you execute programs on remote systems, but they can be a pain to set up and require that you install client software on the remote systems that you wish to access. PsExec is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software. PsExec's most powerful uses include launching interactive command-prompts on remote systems and remote-enabling tools like IpConfig that otherwise do not have the ability to show information about remote systems.
Note: some anti-virus scanners report that one or more of the tools are infected with a "remote admin" virus. None of the PsTools contain viruses, but they have been used by viruses, which is why they trigger virus notifications.
Top of page
Installation
Just copy PsExec onto your executable path. Typing "psexec" displays its usage syntax.
PsExec works on Windows Server 2008, Vista, NT 4.0, Win2K, Windows XP and Server 2003 including x64 versions of Windows.
Top of page
Usage
See the July 2004 issue of Windows IT Pro Magazine for Mark's article that covers advanced usage of PsExec.
usage: psexec [\\computer[,computer2[,...] | @file][-u user [-p psswd]][-n s][-l][-s|-e][-x][-i [session]][-c [-f|-v]][-w directory][-d][-
computer
Direct PsExec to run the application on the computer or computers specified. If you omit the computer name PsExec runs the application on the local system and if you enter a computer name of "\\*" PsExec runs the applications on all computers in the current domain.
@file
Directs PsExec to run the command on each computer listed in the text file specified.
-a
Separate processors on which the application can run with commas where 1 is the lowest numbered CPU. For example, to run the application on CPU 2 and CPU 4, enter: "-a 2,4"
-c
Copy the specified program to the remote system for execution. If you omit this option then the application must be in the system's path on the remote system.
-d
Don't wait for application to terminate. Only use this option for non-interactive applications.
-e
Does not load the specified account's profile.
-f
Copy the specified program to the remote system even if the file already exists on the remote system.
-i
Run the program so that it interacts with the desktop of the specified session on the remote system. If no session is specified the process runs in the console session.
-l
Run process as limited user (strips the Administrators group and allows only privileges assigned to the Users group). On Windows Vista the process runs with Low Integrity.
-n
Specifies timeout in seconds connecting to remote computers.
-p
Specifies optional password for user name. If you omit this you will be prompted to enter a hidden password.
-s
Run remote process in the System account .
-u
Specifies optional user name for login to remote computer.
-v
Copy the specified file only if it has a higher version number or is newer on than the one on the remote system.
-w
Set the working directory of the process (relative to the remote computer).
-x
Display the UI on the Winlogon desktop (local system only).
-priority
Specifies -low, -belownormal, -abovenormal, -high or -realtime to run the process at a different priority. Use -background to run at low memory and I/O priority on Vista.
program
Name of the program to execute.
arguments
Arguments to pass (note that file paths must be absolute paths on the target system)
You can enclose applications that have spaces in their name with quotation marks e.g. "psexec \\marklap "c:\long name\app.exe". Input is only passed to the remote system when you press the enter key, and typing Ctrl-C terminates the remote process.
If you omit a username the remote process runs in the same account from which you execute PsExec, but because the remote process is impersonating it will not have access to network resources on the remote system. When you specify a username the remote process executes in the account specified, and will have access to any network resources the account has access to. Note that the password is transmitted in clear text to the remote system.
You can use the current version of PsExec as a Runas replacement when you target the local system because PsExec does not require you to be an administrator.
Top of page
Examples
This article I wrote describes how PsExec works and gives tips on how to use it:
http://www.winnetmag.com/Windows/Issues/IssueID/714/Index.html
The following command launches an interactive command prompt on \\marklap:
psexec \\marklap cmd
This command executes IpConfig on the remote system with the /all switch, and displays the resulting output locally:
psexec \\marklap ipconfig /all
This command copies the program test.exe to the remote system and executes it interactively:
psexec \\marklap -c test.exe
Specify the full path to a program that is already installed on a remote system if its not on the system's path:
psexec \\marklap c:\bin\test.exe
Run Regedit interactively in the System account to view the contents of the SAM and SECURITY keys::
psexec -i -d -s c:\windows\regedit.exe
To run Internet Explorer as with limited-user privileges use this command:
psexec -l -d "c:\program files\internet explorer\iexplore.exe"
Entourage fails to launch (bouncing icon)
Attempting to launch Entourage results in the icon bouncing a couple of times and then nothing.
Check the Console error log: if there is a reference to Stuffit libraries (or anything refering to Stuffit) do a Spotlight search and delete EVERYTHING with Stuffit in the name.
This is a known problem with Entourage 2004 and Stuffit 10 although we have seen it with later version of Stuffit too.
Check the Console error log: if there is a reference to Stuffit libraries (or anything refering to Stuffit) do a Spotlight search and delete EVERYTHING with Stuffit in the name.
This is a known problem with Entourage 2004 and Stuffit 10 although we have seen it with later version of Stuffit too.
UPDATE: We encountered the same problem in Istanbul and the work-around was to go to /Library/CMFSupport and delete the file StuffitEngineShell.cfm. Note: a Spotlight search failed to find this file!
Entoruage Calendar Export
You can use Custom Views to help you get a list of events that you can
drag directly into your local calendar without having to export or copy
events to the Desktop. See if this works:
1. In Entourage switch to the Calendar view.
2. Select File --> New --> Custom View.
3. Name your view something like "All Exchange events" and set the
following criteria:
Item types: select only Calendar Events
Location: "This Calendar" and select your Exchange calendar.
Criteria: Subject Is not "empty"
This assumes that none of your calendar events have a subject of "empty".
4. Click the OK button and then select your Custom View. This will
create a list of items where you can select one or more entries and
drag/drop onto your "Calendar [On My Computer]" icon.
drag directly into your local calendar without having to export or copy
events to the Desktop. See if this works:
1. In Entourage switch to the Calendar view.
2. Select File --> New --> Custom View.
3. Name your view something like "All Exchange events" and set the
following criteria:
Item types: select only Calendar Events
Location: "This Calendar" and select your Exchange calendar.
Criteria: Subject Is not "empty"
This assumes that none of your calendar events have a subject of "empty".
4. Click the OK button and then select your Custom View. This will
create a list of items where you can select one or more entries and
drag/drop onto your "Calendar [On My Computer]" icon.
Return Receipts for Entourage 2004
Note: this will request a return receipt for EVERY mail:
Entourage doesn't include the ability to request a return receipt on a
message-by-message basis, but you can add the header manually to your
account. Go to Tools > Accounts, and open your mail account. Click the
"Options" tab, and under "Additional Headers", type in
"Disposition-Notification-To" (without the quotes) under Header, and your
e-mail address under Value.
Entourage doesn't include the ability to request a return receipt on a
message-by-message basis, but you can add the header manually to your
account. Go to Tools > Accounts, and open your mail account. Click the
"Options" tab, and under "Additional Headers", type in
"Disposition-Notification-To" (without the quotes) under Header, and your
e-mail address under Value.
Entourage 2004 fails to start on: "You do not have write access to the Entourge application folder"
Launching Entourage kicks back an error saying:
"You do not have write access to the Entourage application folder. To run Entourage you must have the administrative user remove the Identities folder from the application folder. For more information, see the Entourage Read Me file."
After messing around with permissions, re-installing and the like, we found that the solution was to delete the Entourage Temp folder from ~/Documents/Microsoft User Data Folder. If that doesn't do the trick, try moving the entire Microsfot User Data folder to the desktop and then launch Entourage.
The folder contains lots of saved information about the user so moving or deleting it will pretty much reset Office to it's base state.
"You do not have write access to the Entourage application folder. To run Entourage you must have the administrative user remove the Identities folder from the application folder. For more information, see the Entourage Read Me file."
After messing around with permissions, re-installing and the like, we found that the solution was to delete the Entourage Temp folder from ~/Documents/Microsoft User Data Folder. If that doesn't do the trick, try moving the entire Microsfot User Data folder to the desktop and then launch Entourage.
The folder contains lots of saved information about the user so moving or deleting it will pretty much reset Office to it's base state.
Entourage LDAP searches fail
Check that the Windows DC that Entourage is looking to for LDAP info is a Global Catalog Server as well as a Domain Controller.
Changing short names in OS X (very difficult)
his article talks about how to change the user's short name in OS X. The section that most interests us is the descriptions of the best way to copy the old user's Home directory contents into that of a new user.
The full Mac tech article is here:
http://docs.info.apple.com/article.html?artnum=106824
The relevant bits for us are:
Though there are methods by which an advanced user may change the short name and related information, the easier and safer workaround is to create a new user with the desired name, then copy the old user's Home directory contents into that of the new user. Follow these steps:
1. Optional step: As a precaution, you may disable automatic login prior to performing this procedure. You might want to back up important data, too. In the event that you restart the computer for any reason before completing the procedure, this would prevent complications from having displaced the user selected for automatic login. For Mac OS X 10.1.5 or earlier, automatic login is found in the Login preference pane. For Mac OS X 10.2 and 10.3, it is found in the Accounts preference pane.
2. Mac OS X 10.3 or later: If FileVault is on, temporarily turn it off, which will log you out.
3. Enable the root user, then log in as root. For further explanation of this step, see "Mac OS X: About the root User and How to Enable It".
4. For Mac OS X 10.2 or later: Open the Accounts pane of the System Preferences application.
For Mac OS X 10.1.5 or earlier: Open the Users pane of System Preferences.
5. In the Name list, locate the user with the short name that you want to replace. This will be referred to as the "original user".
6. Note whether or not the original user is identified as Admin, which appears in the Kind column to the right.
7. Click New User. For 10.3, this is the plus (+) button.
8. Complete the Name and Short Name fields as desired. Be sure that the Short Name is exactly as you want it to appear.
9. For Mac OS X 10.2: Fill in the New Password and Verify fields.
For Mac OS X 10.1.5. or earlier: Click the password tab, then fill in the Password and Verify fields.
10. If the user you are replacing is an Admin user, then select the checkbox for "Allow user to administer this computer". For 10.3, click the Security tab to locate this setting.
Note: This checkbox is dimmed and already selected if there is not another Admin user. Mac OS X requires at least one Admin user.
11. Click Save. (Skip this step for 10.3.)
12. Quit System Preferences.
13. Click the Finder icon in the Dock.
14. Choose Computer from the Go menu.
15. Open the Users folder in the Mac OS X disk.
16. Open the folder with the short name of the new user that you just created.
17. Drag the contents of this folder to the Trash.
Warning: Do not empty the Trash yet. In the event that you accidentally move contents of the wrong folder, you may recover them from the Trash after discovering your mistake.
18. Choose New Finder Window from the File menu. Be sure to position the new window so that you can see both Finder windows.
19. In the new window, open the folder of the original user.
20. Press the Option key as you drag the contents of the original user's folder into the new user's folder (that you emptied in Step 16). This makes a copy of the contents.
21. Close one of the Finder windows.
22. Open the Terminal application (located at /Applications/Utilities/).
23. Type: chown -R /Users/
Important: Replace "" with the actual short name of the new user you just created. For example, if the new user had the short name "jacques", you would type:
chown -R jacques /Users/jacques
24. Press Return
25. Quit Terminal.
26. Choose Log Out from the Apple menu.
27. Log in as the new user. You should be able to access all of your original files on the desktop and in the folders of the Home directory.
Important: If you do not have access to your original items, log out and log back in as root, then repeat Step 22. Also, be sure that you did not place the wrong files in the Trash in Step 16.
28. Choose Home from the Go menu.
29. Open the Library folder, then the Keychains folder inside it.
30. Select the keychain, which should still have the short name of the original user.
31. Choose Show Info from the File menu.
32. In the Info window that appears, choose Name & Extension from the pop-up menu.
33. Change the name to match the new user's short name.
34. Close the Info window.
35. Open the Keychain Access application, located in the Utilities folder.
36. From the Edit menu, choose " Settings". For the user Jacques, this would appear as: jacques Settings
37. Click Change Passphrase.
38. Enter the desired password, then click OK. You may use the same password again or set it to match the login password of the new user.
Note: This step prevents you from discovering later that the keychain had retained an older password.
39. Quit Keychain Access.
40. Disable the root user, as explained in Section III of technical document 106290, "Mac OS X: About the root User and How to Enable It".
Notes
1. If everything is working correctly, you do not need to log back in as root to empty the Trash. The folders you put there occupy a negligible amount of disk space.
2. Depending on what software you have installed, you may wish to rename other files and folders that may have been created under the original user short name to match the new user short name.
3. Once you are certain that everything is working properly, you may want to delete the Home directory (folder) of the original user, which should be empty. For instructions on how to do this, see technical document 106256, "Mac OS X: Deleting a Former User's Home Directory (Folder)".
The full Mac tech article is here:
http://docs.info.apple.com/article.html?artnum=106824
The relevant bits for us are:
Though there are methods by which an advanced user may change the short name and related information, the easier and safer workaround is to create a new user with the desired name, then copy the old user's Home directory contents into that of the new user. Follow these steps:
1. Optional step: As a precaution, you may disable automatic login prior to performing this procedure. You might want to back up important data, too. In the event that you restart the computer for any reason before completing the procedure, this would prevent complications from having displaced the user selected for automatic login. For Mac OS X 10.1.5 or earlier, automatic login is found in the Login preference pane. For Mac OS X 10.2 and 10.3, it is found in the Accounts preference pane.
2. Mac OS X 10.3 or later: If FileVault is on, temporarily turn it off, which will log you out.
3. Enable the root user, then log in as root. For further explanation of this step, see "Mac OS X: About the root User and How to Enable It".
4. For Mac OS X 10.2 or later: Open the Accounts pane of the System Preferences application.
For Mac OS X 10.1.5 or earlier: Open the Users pane of System Preferences.
5. In the Name list, locate the user with the short name that you want to replace. This will be referred to as the "original user".
6. Note whether or not the original user is identified as Admin, which appears in the Kind column to the right.
7. Click New User. For 10.3, this is the plus (+) button.
8. Complete the Name and Short Name fields as desired. Be sure that the Short Name is exactly as you want it to appear.
9. For Mac OS X 10.2: Fill in the New Password and Verify fields.
For Mac OS X 10.1.5. or earlier: Click the password tab, then fill in the Password and Verify fields.
10. If the user you are replacing is an Admin user, then select the checkbox for "Allow user to administer this computer". For 10.3, click the Security tab to locate this setting.
Note: This checkbox is dimmed and already selected if there is not another Admin user. Mac OS X requires at least one Admin user.
11. Click Save. (Skip this step for 10.3.)
12. Quit System Preferences.
13. Click the Finder icon in the Dock.
14. Choose Computer from the Go menu.
15. Open the Users folder in the Mac OS X disk.
16. Open the folder with the short name of the new user that you just created.
17. Drag the contents of this folder to the Trash.
Warning: Do not empty the Trash yet. In the event that you accidentally move contents of the wrong folder, you may recover them from the Trash after discovering your mistake.
18. Choose New Finder Window from the File menu. Be sure to position the new window so that you can see both Finder windows.
19. In the new window, open the folder of the original user.
20. Press the Option key as you drag the contents of the original user's folder into the new user's folder (that you emptied in Step 16). This makes a copy of the contents.
21. Close one of the Finder windows.
22. Open the Terminal application (located at /Applications/Utilities/).
23. Type: chown -R
Important: Replace "
chown -R jacques /Users/jacques
24. Press Return
25. Quit Terminal.
26. Choose Log Out from the Apple menu.
27. Log in as the new user. You should be able to access all of your original files on the desktop and in the folders of the Home directory.
Important: If you do not have access to your original items, log out and log back in as root, then repeat Step 22. Also, be sure that you did not place the wrong files in the Trash in Step 16.
28. Choose Home from the Go menu.
29. Open the Library folder, then the Keychains folder inside it.
30. Select the keychain, which should still have the short name of the original user.
31. Choose Show Info from the File menu.
32. In the Info window that appears, choose Name & Extension from the pop-up menu.
33. Change the name to match the new user's short name.
34. Close the Info window.
35. Open the Keychain Access application, located in the Utilities folder.
36. From the Edit menu, choose "
37. Click Change Passphrase.
38. Enter the desired password, then click OK. You may use the same password again or set it to match the login password of the new user.
Note: This step prevents you from discovering later that the keychain had retained an older password.
39. Quit Keychain Access.
40. Disable the root user, as explained in Section III of technical document 106290, "Mac OS X: About the root User and How to Enable It".
Notes
1. If everything is working correctly, you do not need to log back in as root to empty the Trash. The folders you put there occupy a negligible amount of disk space.
2. Depending on what software you have installed, you may wish to rename other files and folders that may have been created under the original user short name to match the new user short name.
3. Once you are certain that everything is working properly, you may want to delete the Home directory (folder) of the original user, which should be empty. For instructions on how to do this, see technical document 106256, "Mac OS X: Deleting a Former User's Home Directory (Folder)".
Outlook over https
From MS article: http://office.microsoft.com/en-us/outlook/HP010030591033.aspx
This feature requires you to be using a Microsoft Exchange Server 2003 e-mail account. If you do not know what version of Exchange server your e-mail account is using, contact your Exchange administrator. If your computer and server do not meet the complete requirements for this feature, these options will not be available.
These steps are for connecting Microsoft Outlook to your Exchange server without using a virtual private network (VPN) (virtual private network (VPN): Extension of a private network encompassing encapsulated, encrypted, and authenticated links across shared or public networks. VPN connections provide remote access and connections to private networks over the Internet.) or other security hardware to connect behind your organization's firewall. Your Exchange administrator must enable this feature first before you can use it.
1. On the Tools menu, click E-mail accounts, select View or change existing e-mail accounts, click Next, select the Exchange e-mail account, and then click Change.
2. Click More Settings, then click the Connection tab.
3. Under Exchange over the Internet, select Connect to my Exchange mailbox using HTTP.
To specify a proxy server, click Exchange proxy settings.
Note If you use Basic Password Authentication or Password Authentication (NTLM) and an LM Compatibility Level less than 2, you will be prompted for a password each time a connection is made to the Exchange server. For more information on the LM Compatibility Level registry setting, see the Microsoft Knowledge Base for article number 147706. With Basic Password Authentication, the password is sent in clear text. For increased security, it is recommended that you use Password Authentication (NTLM), Connect with SSL only, and Mutually authenticate the session when connecting with SSL. In order to use mutual authentication, you must also specify the principal name of the server.
This feature requires you to be using a Microsoft Exchange Server 2003 e-mail account. If you do not know what version of Exchange server your e-mail account is using, contact your Exchange administrator. If your computer and server do not meet the complete requirements for this feature, these options will not be available.
These steps are for connecting Microsoft Outlook to your Exchange server without using a virtual private network (VPN) (virtual private network (VPN): Extension of a private network encompassing encapsulated, encrypted, and authenticated links across shared or public networks. VPN connections provide remote access and connections to private networks over the Internet.) or other security hardware to connect behind your organization's firewall. Your Exchange administrator must enable this feature first before you can use it.
1. On the Tools menu, click E-mail accounts, select View or change existing e-mail accounts, click Next, select the Exchange e-mail account, and then click Change.
2. Click More Settings, then click the Connection tab.
3. Under Exchange over the Internet, select Connect to my Exchange mailbox using HTTP.
To specify a proxy server, click Exchange proxy settings.
Note If you use Basic Password Authentication or Password Authentication (NTLM) and an LM Compatibility Level less than 2, you will be prompted for a password each time a connection is made to the Exchange server. For more information on the LM Compatibility Level registry setting, see the Microsoft Knowledge Base for article number 147706. With Basic Password Authentication, the password is sent in clear text. For increased security, it is recommended that you use Password Authentication (NTLM), Connect with SSL only, and Mutually authenticate the session when connecting with SSL. In order to use mutual authentication, you must also specify the principal name of the server.
Unable to log in to a bound Mac (Tiger only)
Symptom: A user on a bound Mac is unable to log in; they receive the "shaky" log-in box at each authentication attempt. Other users can log into the machine and the same user can log into other machines.
Fix: Log on as admin and open Netinfo Manager and select "Users" in the middle column. In the right-hand column the user should be listed ONCE. If the user is listed TWICE, delete both users. Restart and the user should be able to log back in
Fix: Log on as admin and open Netinfo Manager and select "Users" in the middle column. In the right-hand column the user should be listed ONCE. If the user is listed TWICE, delete both users. Restart and the user should be able to log back in
Error -50: Macs can't connect to SMB shares (from MacFixIT)
Error (-50) when connecting to SMB shares
An ongoing problem through recent versions of Mac OS X is a recurring "Error -50" message (with failure to connect) when attempting to mount SMB shares over a local network.
We've previously offered the following solutions to this problem, though a number of users have not found success in applying them:
Modify smb.conf file Open the file /usr/local/samba/lib/smb.conf in a text editor, or type sudo vi /etc/smb.conf in the Terminal (located in Applications/Utilities) open the file in the built-in vi text editor.
Find the line encrypt passwords = yes. This line determines whether or not your Mac will encrypt passwords before sending them. Depending on the configuration of the SMB server to which you are connecting, this line either needs to be commented (disabled) or uncommented (enabled). You can make it commented by putting a semi-colon (;) in front of it, or make it uncommented by removing the semi-colon.
You can also manipulate SMB settings through a GUI with the freeware utility SharePoints.
Re-establishing keychain passwords Deleting then re-entering passwords associated with specific servers can resolve some SMB networking issues. A good way to test whether or not this workaround will bear fruit is to create a new user account (as described in this tutorial) and check for access to the problematic SMB server. If it works, your keychain passwords may be to blame. Go back to the original account, and launch Keychain Access (located in Applications/Utilities). Look for any items that might be related to your SMB server. Delete, then re-establish them.
Try using "Connect to Server" instead of browsing Select the "Go" menu in the Finder and scroll down to the "Connect to Server" option (also accessible through the keyboard combination Command-K) then type SMB://[server name], rather than attempting to browse for servers in the Finder.
Enable CIFS on the server Ask your system administrator to enable CIFS on the server, and attempt to connect via that protocol instead of SMB.
Enable AFP server Ask your system administrator to enable AFP (Apple filesharing protocol) on the server, and attempt to connect via that protocol instead of SMB. AFP is generally faster when accepting access from Macs in any case.
Upgrade to Mac OS X 10.4.x (Tiger) For some users, Mac OS X 10.4.x is able to connect to the same SMB shares that Mac OS X 10.3.x is not.
Upgrade server to Windows 2003 Some users have experienced SMB connection issues when connecting to SMB-enabled Windows 200 servers, but not when connecting to Windows 2003 servers.
Don't block UDP port traffic If you have a Firewall enabled, use the following process to un-block UDP port traffic:
* Open System Preferences
* Select the "Sharing" pane
* Select the "Firewall" tab
* Click the "Advanced..." button
* Turn off the option to the "Block UDP traffic"
As such, we're seeking further input on this issue. If you've experienced a -50 error when attempting to mount SMB shares, please let us know the circumstances and any potential resolution.
Note that a separate -50 error sometimes occurs when attempting to download purchased music from the iTunes Store.
An ongoing problem through recent versions of Mac OS X is a recurring "Error -50" message (with failure to connect) when attempting to mount SMB shares over a local network.
We've previously offered the following solutions to this problem, though a number of users have not found success in applying them:
Modify smb.conf file Open the file /usr/local/samba/lib/smb.conf in a text editor, or type sudo vi /etc/smb.conf in the Terminal (located in Applications/Utilities) open the file in the built-in vi text editor.
Find the line encrypt passwords = yes. This line determines whether or not your Mac will encrypt passwords before sending them. Depending on the configuration of the SMB server to which you are connecting, this line either needs to be commented (disabled) or uncommented (enabled). You can make it commented by putting a semi-colon (;) in front of it, or make it uncommented by removing the semi-colon.
You can also manipulate SMB settings through a GUI with the freeware utility SharePoints.
Re-establishing keychain passwords Deleting then re-entering passwords associated with specific servers can resolve some SMB networking issues. A good way to test whether or not this workaround will bear fruit is to create a new user account (as described in this tutorial) and check for access to the problematic SMB server. If it works, your keychain passwords may be to blame. Go back to the original account, and launch Keychain Access (located in Applications/Utilities). Look for any items that might be related to your SMB server. Delete, then re-establish them.
Try using "Connect to Server" instead of browsing Select the "Go" menu in the Finder and scroll down to the "Connect to Server" option (also accessible through the keyboard combination Command-K) then type SMB://[server name], rather than attempting to browse for servers in the Finder.
Enable CIFS on the server Ask your system administrator to enable CIFS on the server, and attempt to connect via that protocol instead of SMB.
Enable AFP server Ask your system administrator to enable AFP (Apple filesharing protocol) on the server, and attempt to connect via that protocol instead of SMB. AFP is generally faster when accepting access from Macs in any case.
Upgrade to Mac OS X 10.4.x (Tiger) For some users, Mac OS X 10.4.x is able to connect to the same SMB shares that Mac OS X 10.3.x is not.
Upgrade server to Windows 2003 Some users have experienced SMB connection issues when connecting to SMB-enabled Windows 200 servers, but not when connecting to Windows 2003 servers.
Don't block UDP port traffic If you have a Firewall enabled, use the following process to un-block UDP port traffic:
* Open System Preferences
* Select the "Sharing" pane
* Select the "Firewall" tab
* Click the "Advanced..." button
* Turn off the option to the "Block UDP traffic"
As such, we're seeking further input on this issue. If you've experienced a -50 error when attempting to mount SMB shares, please let us know the circumstances and any potential resolution.
Note that a separate -50 error sometimes occurs when attempting to download purchased music from the iTunes Store.
Hotfix for Mac JPGs not appearing in Outlook 2003
http://support.microsoft.com/default.aspx?scid=kb;EN-US;951678
Bulk change AD passwords
Dump usernames from AD into a csv, then create a batch file using the line below (for eg). Make sure it you dump actual logon ids, NOT display names etc
FOR "tokens=1 delims=," /F %I in (amsusers.csv) do NET USER %I Password77 /DOMAIN
For "Password77" enter your desired password.
FOR "tokens=1 delims=," /F %I in (amsusers.csv) do NET USER %I Password77 /DOMAIN
For "Password77" enter your desired password.
Outlook 2007 asking for certificate
Using a new Exchange 2007 server- Outlook 2007 clients keep prompting to download certificates. This is a known problem and MS has released a hotfix:
http://support.microsoft.com/kb/943359/en-u
http://support.microsoft.com/kb/943359/en-u
"moveuser" fails: registry hack to bind XP
Below are the complete steps to ensure it works 100%. In my experience, a lot of the time you can skip re-perming the profile folder (for eg), but to make sure it works all the time, every time you just:
1. Make sure you know the correct full path of the actual profile in use (sometimes users may already have a newer profile with a . extension on it.)
2. Login as the IPGEMEA user (to create the new profile with the correct user SID). Wait for about 2 minutes to ensure the profile is fully created.
3. Log out, and back in as Local or Domain Admin.
4. Reperm the original using the Permissions Tab/Advanced. Add the user to the perms and remove any S-12341232313123123 non-resolved perms. Make sure you click the bottom checkbox (reset all permissions)
5. Run regedit (not regedt32), navigate to HKEY_LOCAL_MACHINE (just select this level)
6. Then File/Load Hive Browse to users original ntuser.dat (if hidden files are not displayed, just manually type the filename). You’ll be prompted to name the hive (call it whatever you like (asdf))
7. Select the hive name and Right click/Permissions and do the same you would for the file perms (add the user, tick checkbox to replace all perms). Sometimes you will receive an error saying that not all the hives could be repermed (this is usually not a problem)
8. VERY IMPORTANT – Unload the Hive as the Administrator will lock this hive and you will get a TEMP profile if you attempt to login as the user, it will not be unlocked unless you a) unload it b) reboot.
9. Whilst still in regedit navigate to the ol’ HKLM\Software\Microsoft\Windows NT\Currentversion\Profilelist and find the profile with the profileimagepath of the newly created profile:
%SystemDrive%\Documents and Settings\(usually firstname.lastname.ipgemea) and remove the .ipgemea bit OR whatever the path is you have from step 1
1. Optional – reboot
2. Now you should be able to login as the user with the correct profile.
3. Congratulate yourself on being a reghack guru and drink a well deserved beer.
Think that’s it…
1. Make sure you know the correct full path of the actual profile in use (sometimes users may already have a newer profile with a .
2. Login as the IPGEMEA user (to create the new profile with the correct user SID). Wait for about 2 minutes to ensure the profile is fully created.
3. Log out, and back in as Local or Domain Admin.
4. Reperm the original using the Permissions Tab/Advanced. Add the user to the perms and remove any S-12341232313123123 non-resolved perms. Make sure you click the bottom checkbox (reset all permissions)
5. Run regedit (not regedt32), navigate to HKEY_LOCAL_MACHINE (just select this level)
6. Then File/Load Hive Browse to users original ntuser.dat (if hidden files are not displayed, just manually type the filename). You’ll be prompted to name the hive (call it whatever you like (asdf))
7. Select the hive name and Right click/Permissions and do the same you would for the file perms (add the user, tick checkbox to replace all perms). Sometimes you will receive an error saying that not all the hives could be repermed (this is usually not a problem)
8. VERY IMPORTANT – Unload the Hive as the Administrator will lock this hive and you will get a TEMP profile if you attempt to login as the user, it will not be unlocked unless you a) unload it b) reboot.
9. Whilst still in regedit navigate to the ol’ HKLM\Software\Microsoft\Windows NT\Currentversion\Profilelist and find the profile with the profileimagepath of the newly created profile:
%SystemDrive%\Documents and Settings\(usually firstname.lastname.ipgemea) and remove the .ipgemea bit OR whatever the path is you have from step 1
1. Optional – reboot
2. Now you should be able to login as the user with the correct profile.
3. Congratulate yourself on being a reghack guru and drink a well deserved beer.
Think that’s it…
Macs dropping connections to Windows servers
Problem: Macs will lose their connections to Windows 2003 servers at random intervals. This will even happen while a user is working on the server.
Solution: Read MS KB: http://support.microsoft.com/default.aspx?scid=kb;en-us;297684
From a command line on the server type:
"net config server /autodisconnect:-1"
This will turn off the auto disconnect service on the server.
You can also try this:
On the server go to Start/Programs/Admin Tools
Go to Local Security Policy/Local Policies
Find the line that says "Amount of idle time required before suspending session" and set it to 0
Solution: Read MS KB: http://support.microsoft.com/default.aspx?scid=kb;en-us;297684
From a command line on the server type:
"net config server /autodisconnect:-1"
This will turn off the auto disconnect service on the server.
You can also try this:
On the server go to Start/Programs/Admin Tools
Go to Local Security Policy/Local Policies
Find the line that says "Amount of idle time required before suspending session" and set it to 0
Changing OS X passwords via ARD and Command Line
This can be used for both Admin and normal user accounts (you have to have the short account name):
You can use ARD to change the admin password on the client workstations. Using the 'Send UNIX Command' to send the following command. Set "root" (sans quote marks) in the User field in the command window.
dscl . -passwd /Users/admin newpassword
replacing admin with the short name of your workstations' local admin account and newpassword with, of course, the new password. Avoid using some characters like spaces, single quotes, double quotes and other non-alphanumeric characters since they may do things in the UNIX shell that you're not going to expect. You should also TEST this with a single client (then maybe a few more) first before trying to change a large number of machines all at once. It would also be wise to have a second local admin account just in case things go wrong.
If this fails you might have to put "sudo -s" in front of the command.
You can use ARD to change the admin password on the client workstations. Using the 'Send UNIX Command' to send the following command. Set "root" (sans quote marks) in the User field in the command window.
dscl . -passwd /Users/admin newpassword
replacing admin with the short name of your workstations' local admin account and newpassword with, of course, the new password. Avoid using some characters like spaces, single quotes, double quotes and other non-alphanumeric characters since they may do things in the UNIX shell that you're not going to expect. You should also TEST this with a single client (then maybe a few more) first before trying to change a large number of machines all at once. It would also be wise to have a second local admin account just in case things go wrong.
If this fails you might have to put "sudo -s" in front of the command.
Bound Macs not connecting to Windows servers via SMB (error -36)
The first thing to do is check that the time on the sever and clients are in sync. If it is more than 5 min out- Kerberos authentication fails. Generally the clients will see an "error -36" when this happens.
If the clients continue to have problems you might have to make adjustments to the security settings on the Windows server. If it is a server which is bound to IPGEMEA you will have to get the Directory Team to make GPO changes for you.
Here is a solution from the Apple discussion boards:
I just finished battling this on a large (200+ Macs) heterogenous network with Windows Server 2003 and Windows Server 2008 domain controllers / file servers.
To use SMB connections with Windows 2003 servers on 10.4 you must first disable SMB packet signing on the server. To do this I think you must... (Props to nmonkee for description on another thread)
To disable SMB signing:
Open Default Domain Controller Security Settings.
Go to Security Settings, Local Policies, security Options.
Disable the following:
Domain member: Digitaly encrypt or sign secure Channel Data (Always)
Microsoft network server: Digitally sign communications (Always)
Microsoft network server: Digitally sign communications (If client agrees)
To refresh the policy:
from a command prompt run gpupdate
Doing this alone did not solve my problem with 10.4.11 Macs connecting. Now they could connect, but the shares appear 'empty'. To solve this I had to permit the user/group to List Folder Contents in the security tab when looking at the share properties.
Once I made this change, the structure and contents of the share was visible, and all other permissions were working properly.
*Note - if the destination share is inside another share, all shares all the way down to the root share must have List Folder Contents active for all 10.4 users, all the way up to the destination share. This can be controlled with individual user permissions or with a specific group for tighter security.
The end result of this type of solution is that if a group of users has List Folder Contents privileges for a root share all the way down to an individual share, they can see the directory structure of the root share all the way down to their destination share, but cannot see the files inside any directory but their own.
Prior to these changes, 10.5 could not connect via SMB, but then after disabling SMB packet signing on the Windows 2003 server, 10.5 could navigate the shares properly. The permissions fix is only for 10.4, and possibly earlier.
I am connecting to SMB this way:
Go Menu>Connect to server...>smb:///the/share/path
Then authenticating against Active Directory.
I place the destination share in the dock for easy access by the end user.
Another note - the root share point is what mounts to 10.4, so if you have a Users directory, then Adam, then Work, the directory that will appear on the left side of the finder window and on the desktop is Users, not the Work directory.
If the clients continue to have problems you might have to make adjustments to the security settings on the Windows server. If it is a server which is bound to IPGEMEA you will have to get the Directory Team to make GPO changes for you.
Here is a solution from the Apple discussion boards:
I just finished battling this on a large (200+ Macs) heterogenous network with Windows Server 2003 and Windows Server 2008 domain controllers / file servers.
To use SMB connections with Windows 2003 servers on 10.4 you must first disable SMB packet signing on the server. To do this I think you must... (Props to nmonkee for description on another thread)
To disable SMB signing:
Open Default Domain Controller Security Settings.
Go to Security Settings, Local Policies, security Options.
Disable the following:
Domain member: Digitaly encrypt or sign secure Channel Data (Always)
Microsoft network server: Digitally sign communications (Always)
Microsoft network server: Digitally sign communications (If client agrees)
To refresh the policy:
from a command prompt run gpupdate
Doing this alone did not solve my problem with 10.4.11 Macs connecting. Now they could connect, but the shares appear 'empty'. To solve this I had to permit the user/group to List Folder Contents in the security tab when looking at the share properties.
Once I made this change, the structure and contents of the share was visible, and all other permissions were working properly.
*Note - if the destination share is inside another share, all shares all the way down to the root share must have List Folder Contents active for all 10.4 users, all the way up to the destination share. This can be controlled with individual user permissions or with a specific group for tighter security.
The end result of this type of solution is that if a group of users has List Folder Contents privileges for a root share all the way down to an individual share, they can see the directory structure of the root share all the way down to their destination share, but cannot see the files inside any directory but their own.
Prior to these changes, 10.5 could not connect via SMB, but then after disabling SMB packet signing on the Windows 2003 server, 10.5 could navigate the shares properly. The permissions fix is only for 10.4, and possibly earlier.
I am connecting to SMB this way:
Go Menu>Connect to server...>smb://
Then authenticating against Active Directory.
I place the destination share in the dock for easy access by the end user.
Another note - the root share point is what mounts to 10.4, so if you have a Users directory, then Adam, then Work, the directory that will appear on the left side of the finder window and on the desktop is Users, not the Work directory.
Greek Characters not appearing in sent mail (Entourage)
Problem: LWW Athens Entourage users were sending mail with Greek characters but the recipients got a line of ????? instead of the characters.
Cause: By default Entourage uses the character set that the machine was built in, in this case, US English, and there is no way to force it to use another by default.
Work-around 1: Users can simply select Format/Character set/UTF-8 when they are composing a new mail message. This will allow them to use Greek and other non-latin characters.
Work-around 2: Create a default signature with a Unicode character in it. This will force all mail to be sent as Unicode and the Greek character set will display properly for the recipient.
Go to Tools/Signature to create or modify an existing signature
Add the € symbol to the signature (the € works best)
Reduce the font size to as small as possible (8pt)
Highlight the € and change the font color to white
Save the signature
Under Accounts Settings/Options make the default signature the one you modified with the € symbol
This will force all e-mails to use UTF-8 (the users will get a warning that they can disable)
Cause: By default Entourage uses the character set that the machine was built in, in this case, US English, and there is no way to force it to use another by default.
Work-around 1: Users can simply select Format/Character set/UTF-8 when they are composing a new mail message. This will allow them to use Greek and other non-latin characters.
Work-around 2: Create a default signature with a Unicode character in it. This will force all mail to be sent as Unicode and the Greek character set will display properly for the recipient.
Go to Tools/Signature to create or modify an existing signature
Add the € symbol to the signature (the € works best)
Reduce the font size to as small as possible (8pt)
Highlight the € and change the font color to white
Save the signature
Under Accounts Settings/Options make the default signature the one you modified with the € symbol
This will force all e-mails to use UTF-8 (the users will get a warning that they can disable)
InDesign CS2 or CS3 locking on SING at startup
Problem: ID CS2 and CS3 lock on the startup splash screen when the pre-launch checks reach the SING plug in.
Solution: change the permissions on the SING folder
sudo chmod -R 777 /Library/Application Support/Adobe/SING
Solution: change the permissions on the SING folder
sudo chmod -R 777 /Library/Application Support/Adobe/SING
Binding Macs from the command line
sudo dsconfigad -f -a [computer name] -domain emea.corp.ipgnetwork.com -status -u service.macbind -p [password]
Very good site for Directory Serives (Mac binding) troubleshooting
http://developer.apple.com/releasenotes/MacOSXServer/RN-DirectoryServicesSession549/index.html
Mac won't bind: unable to verify user name or password
Symptom: When attempting to bind a Mac (Tiger or Leopard) the bind process fails when it is attempting to verify the username and password used for binding. The error says something like "unable to verify user name or password, check the user name and password are correct and try again."
Solution:
Make sure you have a modified edu.mit.kerberos file which has been configured for the site you are at.
Log in as admin and enable the root user
Delete library/preferences/Directory Services folder
If it exists, delete the edu.mit.kerberos file in library/preferences
Restart the Mac and log in as root
Attempt to bind the Mac manually. This will undoubtedly fail but that's OK, it generates a new edu.mit.kerberos file which we will need in the next steps
Go to /library/preferences and open up the edu.mit.kerberso file using text edit
The file will be very sparse. What you are looking for is the line that says [libdefaults]. Probably the only thing under it will be "dns_fallback = no". Cut and paste from your modified edu.mit.kerberos file everything under [libedfaults]. DO NOT SIMPLY REPLACE THE KERBEROS FILE! Save your changes and attempt to bind again- it SHOULD work this time.
Once the Mac has bound, go back to /library/preferences and open the edu.mit.kerberos file. Chances are it has changed again. As before, replace everything under [libdefaults] with the entries from the modified kerberos file.
Open a Terminal window and type "id [user name]" and make sure it returns the user's info (a bunch of group memberships and GIDs)
Log out and log back in as the user.
Solution:
Make sure you have a modified edu.mit.kerberos file which has been configured for the site you are at.
Log in as admin and enable the root user
Delete library/preferences/Directory Services folder
If it exists, delete the edu.mit.kerberos file in library/preferences
Restart the Mac and log in as root
Attempt to bind the Mac manually. This will undoubtedly fail but that's OK, it generates a new edu.mit.kerberos file which we will need in the next steps
Go to /library/preferences and open up the edu.mit.kerberso file using text edit
The file will be very sparse. What you are looking for is the line that says [libdefaults]. Probably the only thing under it will be "dns_fallback = no". Cut and paste from your modified edu.mit.kerberos file everything under [libedfaults]. DO NOT SIMPLY REPLACE THE KERBEROS FILE! Save your changes and attempt to bind again- it SHOULD work this time.
Once the Mac has bound, go back to /library/preferences and open the edu.mit.kerberos file. Chances are it has changed again. As before, replace everything under [libdefaults] with the entries from the modified kerberos file.
Open a Terminal window and type "id [user name]" and make sure it returns the user's info (a bunch of group memberships and GIDs)
Log out and log back in as the user.
Subscribe to:
Posts (Atom)