OK since I am in a holding pattern on this issue perhaps someone has seen these symptoms and can provide some sage advice. (Note: I have learned only enough Active Directory information to build this feature and I only have read access to the Active Directory.)
I updated the company intranet to allow the automatic entry/modification of employee phone/address information; it uses a web service to connect to the company Active Directory so I can call it from multiple locations in the main application.
The AD has two domains (A and B) in the same forest. Each domain has an ‘ADS update user’ group and an ‘ADSupdate’ account (which belongs to ‘ADS update user’).
Problem: Entries in Domain A update fine for Local Development Servers, Test Servers, and Production Servers. Entries in Domain B update only when run from Local Development Servers. When you run the same code (verified multiple times) on either Test or Production you get a (General access denied error).
The domain name is stored in the employee record so the exact same code is called for all employees.
All Local Development Servers, Test, and Production servers reside in Domain A.
This has the Active Directory Admin for Domain B stumped and to be honest I am thankful that the Local Development Servers are able to update the Active Directory entries in domain B. It proves that the code works at least in one location
I have looked at machine permissions, permissions on the group and user, and IIS and I can spot no significant differences.
Any help would be appreciated…
Is integrated authentication enabled on any of the web service applications?
Are the production application on domain A installed on a domain controller?
Does the updates from the development workstation work when you call the web service from a remote machine?
This was not caused by any code changes. The Production and Test servers were upgraded and run a newer version of IIS (6.0). The newer version of IIS will not work accross Active Directory domains.
My development machine is running the older version of IIS (5.1)
This explains why everthing was working last year and then suddenly stopped working. There are so few employees in the other domain that it was not immediatly noticed.
Related
I have a small Windows domain which became "a little bit" corrupted over time. Now I want to cleanup using an older VM of a DC (WinSrvr 2008R2) with a healthy AD structure. For this I removed the existing DCs physically from the network without downgrading them to normal servers. Then I started up the virtual DC and created some non-DCs successfully. Existing non-virtual workstations, which had been added to the domain after the reanimated server was sent to sleep, allow successful login. I assume that this is possible because the domain users are allowed to login from anywhere. However, these machines cannot access the new VMs besides the reanimated server because they are not known to the domain which is obvious. Also some services run under some domain identities do not start up because these identities are not known to the reanimated server.
Now I read that since WinSrvr 2008R2 it is possible to restore deleted objects from the AD recyle bin. So my hope is it will be possible to restore the objects (users, groups, computers, an possibly some others) from the AD recycle bin. For this, the following procedure appears feasible to me:
Start one of the isolated DCs leaving it isolated
Remove the objects of interest from AD
Export the recycle bin to a file
Import the recycle bin from this file to the reanimated DC
Recover objects from the recycle bin on the reanimated DC
While all this looks consistent to me, I have no idea how to perform steps 3 and 4. Do there exist any experiences of how to do that? I would be really glad.
Correction:
Login from later added computers is not possible anymore. Probably cached credentials expired.
Okay all, the subject is a pretty poor one, but I'm not sure how else to put it. I have Server 2012 with a bunch of jobs, all owned by sa. They all worked fine ever since I began working here in January 2016, but we recently made major changes to our servers. Currently, we have a few servers off the domain, and set up together as a workgroup. They're clones of what we were running before the shakeup, so include all the data/logins. The main difference is that they can't talk to our Active Directory anymore.
Back to SQL Server. Some of the jobs on the server have to read from and write to an FTP folder on one of the servers which is in the same workgroup. That is, both the 2012 server and the FTP server are on the same workgroup, so should talk to each other with no problem. However, some of the jobs keep failing because of logon errors when trying to connect to the FTP server. I'm not using FTP, but rather network locations, like \\1.2.3.4\ftp\folder\file.txt in my job code. This worked perfectly until the servers moved. Skipping the long and confusing reasons why, suffice it to say that this server won't be back in contact with Active Directory for some time. Indeed, letting it be so can't happen until we can shut down its on-domain counterpart. However, we can't do that until I get this working sans domain contact. Again, long story behind that catch-22.
My questions after dealing with all this are:
If the job in question is owned by sa, why do the logs show logon attempts by nt access\network authority?
How/where can I change the username/password the 2012 server is using to talk to the FTP server?
Is there a way I could access the FTP server, given the workgroup setup in place, that's easier than what I'm trying to do now? Sharing settings on the FTP folder, for instance?
Thanks for any explanations anyone can offer. I'm thoroughly confused about permissions, accounts, credentials, and remote access and have no idea where to turn, having googled all of this exhaustively.
I have not worked with servers that were not domain joined, but I have had similar issues when using SSIS accross sub-domains (see original answer below for more detail). I would look at the setup of sql server and see what service accounts were used for the sql database service and the sql agent service (check out https://msdn.microsoft.com/en-us/library/ms143504.aspx). ALso, make sure that the server accounts have permissions to the file system locations (you likely already did that, but just in case).
Original Answer for SSIS Situations ( I misunderstood that the asker wasn't using SSIS):
You might need to set up a proxy to control what account is used. There is a section on proxies in this article that you might find helpful. I suggest reading the entire article, it might shed some light.
https://www.simple-talk.com/sql/database-administration/setting-up-your-sql-server-agent-correctly/
Hi we have two offices at different locations, they are set up on active directory sites and services and the active directory is replicated between the two over a vpn.
I can see all the group policys at the other site and they all look the same but when we log in at the first site they get a default desktop and not the desktop that we have at the first site with programs that are launched at logon.
I guess this must be down to the programs and scripts we have that run on logon but this only happers for some users.
I am not sure what the scripts do currently but i thought i would post this here while im investigating it further incase any of you have encountered anything similar.
Check the domain controller the PCs with the problems are connecting too by running SET at the command prompt of the PC and looking for the logon server
Once you know the logon server or the PC (when it's getting the issue) then open the GPMC and manually connect to this DC (right-click on the Domain and select "Change Domain Controller".
Now check that the GPOs show the settings as expected. If not then it's a replication problem.
I'm absolutely new to DNN world, and I have to migrate a bunch of websites from a web server to another.
Following my expectations and some "guide" on the web, i did:
Exported SqlServer databases from old server
Imported all databases in new server
Copied the whole c:\inetput\vhosts directory from old server to the new one
Created manually the vhosts entries in IIS to host the websites (setting the vhost on the httpdocs dir and converting to application the subfolder "portal"
After some problem with app pool, user permissions, database user configurations etc. i reached to get websites running.
But what it happens is that the websites seems to load the default "theme" instead of the one that was using in production server. What did I forgot?
There is likely an Error that is being thrown with the current "skin" so you'll need to get into the Event Viewer (under the admin page) if you can get logged in, or into the EventLog table in the database to see what errors are being thrown.
select top 50 * From eventlog order by logcreatedate desc
Friends
I have configured WebLogic cluster with 2 managed servers and set crashrecoveryenabled to 'true' in nodemanager.properties so that in case of server crash the managed servers can start automatically.The Node manager and admin server are setup as windows services so that they can start automatically on server reboot. I have 2 questions
1.How can I make sure that the managed servers will start automatically after server reboot(I know adding managed servers as windows service is one option).
2.In nodemanager.properties do I need to set startscriptenabled to true in production environments?
thanks
Setting up a service to have the managed servers start on system reboot is the preferred approach.
I always set startScriptEnabled=true in production environments. This just uses the script to start up the managed servers.
Provided crashRecoveryEnabled is set to true and you have started each of your managed servers then it will start.
You can use wlst to check if they are running (or start them) through some sort of scheduled task if you wish.
EDIT: From the Oracle Documentation 4.2.4 Configuring Node Manager to Start Managed Servers
If a Managed Server contains other Oracle Fusion Middleware products, such as Oracle SOA Suite, Oracle WebCenter Portal, or Oracle JRF, the Managed Servers environment must be configured to set the correct classpath and parameters. This environment information is provided through the start scripts, such as startWebLogic and setDomainEnv, which are located in the domain directory.
If the Managed Servers are started by Node Manager (as is the case when the servers are started by the Oracle WebLogic Server Administration Console or Fusion Middleware Control), Node Manager must be instructed to use these start scripts so that the server environments are correctly configured. Specifically, Node Manager must be started with the property StartScriptEnabled=true.
There are several ways to ensure that Node Manager starts with this property enabled. As a convenience, Oracle Fusion Middleware provides the following script, which adds the property StartScriptEnabled=true to the nodemanager.properties file:
(UNIX) ORACLE_COMMON_HOME/common/bin/setNMProps.sh.
(Windows) ORACLE_COMMON_HOME\common\bin\setNMProps.cmd
For example, on Linux, execute the setNMProps script and start Node Manager:
ORACLE_COMMON_HOME/common/bin/setNMProps.sh
MW_HOME/wlserver_n/server/bin/startNodeManager.sh
When you start Node Manager, it reads the nodemanager.properties file with the StartScriptEnabled=true property, and uses the start scripts when it subsequently starts Managed Servers. Note that you need to run the setNMProps script only once.